Некогаш, или како да се скрши сè со помош на уролог и Роскомнадзор

Оваа статија е напишана врз основа на многу успешниот тест што го спроведоа специјалистите на Group-IB пред неколку години: се случи приказна што може да се адаптира за филм во Боливуд. Сега, веројатно, ќе следи реакцијата на читателот: „Ах, уште една ПР-напис, повторно се прикажуваат овие, колку се добри, не заборавајте да купите пентест“. Па, од една страна, тоа е. Сепак, постојат голем број други причини зошто се појави овој напис. Сакав да покажам што точно прават петерџиите, колку оваа работа може да биде интересна и нетривијална, какви смешни околности може да се појават во проектите и што е најважно, да прикажам материјал во живо со вистински примери.

За да се врати рамнотежата на скромноста во светот, по некое време ќе пишуваме за пентест што не помина најдобро. Ќе покажеме како добро дизајнираните процеси во една компанија можат да заштитат од цела низа напади, дури и од добро подготвени, едноставно затоа што овие процеси постојат и всушност функционираат.

За купувачот во овој напис, сè беше исто така генерално одлично, барем подобро од 95% од пазарот во Руската Федерација, според нашите чувства, но имаше голем број мали нијанси кои формираа долг синџир на настани, кои прво доведе до долг извештај за работата, а потоа и до овој напис.

Значи, да се снабдиме со пуканки и добре дојдовте во детективската приказна. збор - Павел Супрунјук, технички менаџер на одделот „Ревизија и консалтинг“ на Group-IB.

Дел 1. Почкин лекар

2018 година Има клиент - високотехнолошка ИТ компанија, која сама по себе опслужува многу клиенти. Сака да добие одговор на прашањето: дали е можно, без првично знаење и пристап, работејќи преку Интернет, да се добијат администраторски права на доменот на Active Directory? Не сум заинтересиран за социјален инженеринг (ох, но залудно), немаат намера намерно да се мешаат во работата, но може случајно - повторно вчитаат чудно работен сервер, на пример. Дополнителна цел е да се идентификуваат што повеќе други вектори на напад на надворешниот периметар. Компанијата редовно спроведува вакви тестови, а сега дојде рокот за ново тестирање. Условите се речиси типични, адекватни, разбирливи. Ајде да почнеме.

Има име на клиентот - нека биде „Компанија“, со главната веб-страница www.company.ru. Се разбира, клиентот се нарекува поинаку, но во оваа статија сè ќе биде безлично.
Јас спроведувам мрежно извидување - дознајте кои адреси и домени се регистрирани кај клиентот, нацртајте мрежен дијаграм, како се дистрибуираат услугите на овие адреси. Го добивам резултатот: повеќе од 4000 живи IP адреси. Ги гледам домените во овие мрежи: за среќа, огромното мнозинство се мрежи наменети за клиентите на клиентите и ние формално не сме заинтересирани за нив. Муштеријата го мисли истото.

Останува една мрежа со 256 адреси, за која до овој момент веќе има разбирање за распределбата на домени и поддомени по IP адреси, има информации за скенираните порти, што значи дека можете да ги погледнете услугите за интересни. Паралелно, сите видови скенери се лансираат на достапните IP адреси и одделно на веб-локациите.

Има многу услуги. Вообичаено ова е радост за пентестерот и очекување на брза победа, бидејќи колку повеќе услуги има, толку е поголемо полето за напад и полесно е да се најде артефакт. Брзиот поглед на веб-страниците покажа дека повеќето од нив се веб-интерфејси на познати производи на големи светски компании, кои по се изгледа ви кажуваат дека не се добредојдени. Тие бараат корисничко име и лозинка, го тресат полето за внесување на вториот фактор, бараат сертификат за клиент TLS или го испраќаат до Microsoft ADFS. Некои се едноставно недостапни од Интернет. За некои, очигледно треба да имате специјален платен клиент за три плати или да го знаете точниот URL за внесување. Ајде да прескокнеме уште една недела на постепено очајување во процесот на обидот да се „пробие“ софтверските верзии за познати пропусти, пребарувањето скриена содржина во веб-патеките и протечените сметки од трети лица услуги како LinkedIn, обидот да се погодат лозинки користејќи ги, исто така. како ископување ранливости на веб-локации кои сами се напишани - патем, според статистичките податоци, ова е најперспективниот вектор на надворешен напад денес. Веднаш ќе го забележам филмскиот пиштол што потоа пукаше.

Така, најдовме две страници кои се издвојуваа од стотиците услуги. Овие страници имаа едно нешто заедничко: ако не се вклучите во прецизно мрежно извидување по домен, туку гледате директно за отворени порти или насочувате скенер за ранливост користејќи познат опсег на IP, тогаш овие локации ќе избегнат скенирање и едноставно нема да бидат видливи без да се знае името на DNS. Можеби тие беа пропуштени барем порано, а нашите автоматски алатки не најдоа никакви проблеми со нив, дури и ако беа испратени директно до ресурсот.

Патем, за она што го најдоа претходно лансираните скенери воопшто. Дозволете ми да ве потсетам: за некои луѓе, „пентест“ е еквивалентно на „автоматско скенирање“. Но, скенерите на овој проект не кажаа ништо. Па, максимумот го покажаа пропустите со средна вредност (3 од 5 во однос на сериозноста): на некоја услуга лош TLS сертификат или застарени алгоритми за шифрирање и на повеќето сајтови Clickjacking. Но, ова нема да ве доведе до вашата цел. Можеби скенерите би биле покорисни овде, но дозволете ми да ве потсетам: самиот клиент може да купи такви програми и да се тестира со нив, и, судејќи според лошите резултати, тој веќе проверил.

Да се ​​вратиме на „аномалните“ сајтови. Првиот е нешто како локално Вики на нестандардна адреса, но во оваа статија нека биде wiki.company[.]ru. Таа, исто така, веднаш побара најава и лозинка, но преку NTLM во прелистувачот. За корисникот, ова изгледа како аскетски прозорец кој бара да внесе корисничко име и лозинка. И ова е лоша практика.

Мала забелешка. NTLM во периметарските веб-страници е лош поради повеќе причини. Првата причина е што името на доменот на Active Directory е откриено. Во нашиот пример, исто така се покажа дека е company.ru, исто како и „надворешното“ име на DNS. Знаејќи го ова, можете внимателно да подготвите нешто злонамерно за да се изврши само на машината за домен на организацијата, а не во некое песок. Второ, автентикацијата оди директно преку контролорот на доменот преку NTLM (изненадување, нели?), со сите карактеристики на „внатрешните“ мрежни политики, вклучително и блокирање на сметките од надминување на бројот на обиди за внесување лозинка. Ако напаѓачот ги дознае најавувањата, ќе проба лозинки за нив. Ако сте конфигурирани да блокирате сметки од внесување неточни лозинки, тоа ќе работи и сметката ќе биде блокирана. Трето, невозможно е да се додаде втор фактор на таквата автентикација. Ако некој од читателите сè уште знае како, ве молам известете ми, навистина е интересно. Четврто, ранливост на напади со „pas-the-hash“. ADFS е измислен, меѓу другото, за да се заштити од сето ова.

Постои една лоша сопственост на производите на Microsoft: дури и ако конкретно не сте објавиле таков NTLM, тој ќе биде стандардно инсталиран во OWA и Lync, на минимум.

Патем, авторот на оваа статија еднаш случајно блокирал приближно 1000 сметки на вработени во една голема банка за само еден час користејќи го истиот метод, а потоа изгледал малку бледо. ИТ услугите на банката исто така беа бледи, но сè заврши добро и соодветно, дури бевме пофалени што први го пронајдовме овој проблем и предизвикавме брзо и решително решение.

Втората страница имаше адреса „очигледно некакво презиме.company.ru“. Го најдов преку Гугл, вакво нешто на страница 10. Дизајнот беше од почетокот на средината на XNUMX-тите, а угледна личност го гледаше од главната страница, нешто вака:

Овде зедов фотографија од „Кучешко срце“, но верувајте ми беше нејасно слична, дури и дизајнот на боите беше во слични тонови. Нека се вика страницата preobrazhensky.company.ru.

Тоа беше лична веб-страница... за уролог. Се прашував што прави веб-страницата на уролог на поддоменот на компанија со висока технологија. Брзото копање во Google покажа дека овој лекар бил ко-основач на едно од правните лица на нашите клиенти, па дури и придонел околу 1000 рубли во одобрениот капитал. Веројатно страницата е создадена пред многу години, а ресурсите на серверот на клиентот се користеле како хостинг. Веб-страницата одамна ја изгуби својата важност, но поради некоја причина остана да работи долго време.

Во однос на пропустите, самата веб-страница беше безбедна. Гледајќи напред, ќе кажам дека тоа беше збир на статични информации - едноставни html страници со вметнати илустрации во форма на бубрези и мочен меур. Бескорисно е да се „скрши“ таква страница.

Но, веб-серверот одоздола беше поинтересен. Судејќи според насловот на HTTP Server, тој имал 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 часа. Односно, кога контролата излезе од кодот на школка, работниот процес на IIS заврши, потоа се рестартираше неколку пати и потоа одеше на одмор 30 часа.

Бидејќи повратното поврзување со tcp не успеа првиот пат, овој проблем го припишав на затворена порта. Односно, тој претпоставил присуство на некој вид заштитен ѕид кој не дозволувал излезните врски да минуваат надвор. Почнав да пуштам кодови од школки кои пребаруваа низ многу порти за tcp и udp, немаше ефект. Вчитувањата на обратна врска преку http(s) од Metasploit не работеа - meterpreter/reverse_http(s). Одеднаш, беше воспоставена врска со истата порта 80, но веднаш падна. Ова го припишав на дејството на сè уште имагинарниот IPS, на кој не му се допадна сообраќајот на метар преведувач. Со оглед на фактот дека чиста tcp конекција со портата 80 не помина, туку http врската, заклучив дека http-прокси е некако конфигуриран во системот.

Пробав дури и метар преведувач преку DNS (благодарам d00kie за вашите напори, зачувавте многу проекти), потсетувајќи се на првиот успех, но дури и не функционираше на штандот - кодот на школка беше премногу обемен за оваа ранливост.

Во реалноста, изгледаше вака: 3-4 обиди за напади во рок од 5 минути, а потоа чекање 30 часа. И така три недели по ред. Дури поставив потсетник за да не губам време. Дополнително, имаше разлика во однесувањето на тестовите и производните средини: за оваа ранливост постоеја два слични експлоатирања, едната од Metasploit, втората од Интернет, конвертирана од верзијата Shadow Brokers. Значи, само Metasploit беше тестиран во борба, а само вториот беше тестиран на клупата, што го отежна дебагирањето и го разбиваше мозокот.

На крајот, кодот на школка што преземал exe датотека од даден сервер преку http и го лансирал на целниот систем се покажал како ефикасен. Шел-кодот беше доволно мал за да се вклопи, но барем работеше. Бидејќи на серверот воопшто не му се допадна сообраќајот на TCP и http(s) беа проверени за присуство на метар преведувач, решив дека најбрзиот начин е да преземам датотека exe што содржи DNS-meterpreter преку овој шелкод.

Тука повторно се појави проблем: при преземање на датотека exe и, како што покажаа обидите, без разлика кој, преземањето беше прекинато. Повторно, на некој безбедносен уред помеѓу мојот сервер и урологот не му се допадна http сообраќајот со exe внатре. Се чинеше дека „брзото“ решение е да се смени кодот на школка за да се замагли http сообраќајот во лет, така што апстрактните бинарни податоци ќе бидат префрлени наместо exe. Конечно, нападот беше успешен, контролата беше примена преку тенкиот DNS канал:

Веднаш стана јасно дека ги имам најосновните права на работниот тек на IIS, кои ми дозволуваат да не правам ништо. Вака изгледаше на конзолата Metasploit:

Сите методологии на pentest силно сугерираат дека треба да ги зголемите правата кога добивате пристап. Обично не го правам ова локално, бидејќи првиот пристап се гледа едноставно како влезна точка на мрежата, а компромитирањето на друга машина на истата мрежа обично е полесно и побрзо од зголемувањето на привилегиите на постоечкиот хост. Но, ова не е случај овде, бидејќи каналот DNS е многу тесен и нема да дозволи сообраќајот да се расчисти.

Претпоставувајќи дека овој сервер за Windows 2003 не е поправен поради познатата ранливост MS17-010, го тунелирам сообраќајот до портата 445/TCP преку тунелот DNS на метар претерувач на localhost (да, ова е исто така можно) и се обидувам да го извршам претходно преземениот exe преку ранливоста. Нападот работи, добивам втора врска, но со СИСТЕМСКИ права.

Интересно е што тие сепак се обидоа да го заштитат серверот од MS17-010 - имаше оневозможени ранливи мрежни услуги на надворешниот интерфејс. Ова заштитува од напади преку мрежата, но нападот одвнатре на локалниот хост функционираше, бидејќи не можете брзо да го исклучите SMB на локалниот хост.

Следно, се откриваат нови интересни детали:

1. Имајќи СИСТЕМски права, можете лесно да воспоставите повратна врска преку TCP. Очигледно, оневозможувањето на директен TCP е строго проблем за ограничениот корисник на IIS. Спојлер: корисничкиот сообраќај на IIS беше некако завиткан во локалниот ISA прокси во двете насоки. Како точно функционира, не сум репродуцирал.
2. Јас сум во одреден „DMZ“ (и ова не е домен на Active Directory, туку РАБОТНА ГРУПА) - звучи логично. Но, наместо очекуваната приватна („сива“) IP адреса, имам целосно „бела“ IP адреса, точно иста како онаа што ја нападнав претходно. Ова значи дека компанијата е толку стара во светот на IPv4 адресирањето што може да си дозволи да одржува зона DMZ за 128 „бели“ адреси без NAT според шемата, како што е прикажано во прирачниците на Cisco од 2005 година.

Бидејќи серверот е стар, Mimikatz е загарантирана да работи директно од меморијата:

Ја добивам лозинката за локалниот администратор, тунелирам RDP сообраќај преку TCP и се најавувам на пријатна работна површина. Бидејќи можев да правам што сакам со серверот, го отстранив антивирусот и открив дека серверот е достапен од Интернет само преку TCP портите 80 и 443, а 443 не е зафатен. Поставив OpenVPN сервер на 443, додавам NAT функции за мојот VPN сообраќај и добивам директен пристап до мрежата DMZ во неограничена форма преку мојот OpenVPN. Вреди да се одбележи дека ISA, имајќи некои неоневозможени IPS функции, ми го блокираше сообраќајот со скенирање на портите, за што мораше да се замени со поедноставен и поусогласен RRAS. Така, петестерите понекогаш сè уште треба да администрираат секакви работи.

Внимателен читател ќе праша: „Што е со втората страница - вики со NTLM автентикација, за која толку многу е напишано? Повеќе за ова подоцна.

Дел 2. Сè уште не шифрирате? Тогаш доаѓаме кај вас веќе овде

Значи, има пристап до мрежниот сегмент DMZ. Треба да отидете кај администраторот на доменот. Првото нешто што ми паѓа на ум е автоматски да се провери безбедноста на услугите во сегментот DMZ, особено затоа што многу повеќе од нив сега се отворени за истражување. Типична слика за време на тест за пенетрација: надворешниот периметар е подобро заштитен од внатрешните услуги, а кога се добива каков било пристап во голема инфраструктура, многу е полесно да се добијат проширени права во домен само поради фактот што овој домен почнува да биде достапни за алатки, и второ, во инфраструктура со неколку илјади домаќини, секогаш ќе има неколку критични проблеми.

Ги полнам скенерите преку DMZ преку тунел OpenVPN и чекам. Го отворам извештајот - повторно ништо сериозно, очигледно некој поминал низ истиот метод пред мене. Следниот чекор е да се испита како комуницираат домаќините во мрежата DMZ. За да го направите ова, прво стартувајте го вообичаениот Wireshark и слушајте ги барањата за емитување, првенствено ARP. ARP пакетите се собираа цел ден. Излегува дека во овој сегмент се користат неколку порти. Ова ќе ни се најде подоцна. Со комбинирање на податоци за барањата и одговорите на ARP и податоците за скенирање на пристаништа, ги најдов излезните точки на корисничкиот сообраќај од внатрешноста на локалната мрежа, покрај оние услуги што беа претходно познати, како што се веб и пошта.

Бидејќи во моментот немав никаков пристап до други системи и немав ниту една сметка за корпоративни услуги, беше одлучено да извадам барем дел од сообраќајот користејќи ARP Spoofing.

Cain&Abel беше лансиран на серверот на урологот. Земајќи ги предвид идентификуваните текови на сообраќај, беа избрани најперспективните парови за нападот човек во средината, а потоа одреден мрежен сообраќај беше примен со краткорочно стартување за 5-10 минути, со тајмер за рестартирање на серверот во случај на замрзнување. Како и во шегата, имаше две вести:

1. Добро: многу ингеренциите беа фатени и нападот како целина функционираше.
2. Лошото: сите ингеренции беа од клиентите на самите клиенти. Додека обезбедуваат услуги за поддршка, специјалистите за клиенти се поврзани со услугите на клиенти кои не секогаш имале конфигурирано шифрирање на сообраќајот.

Како резултат на тоа, добив многу ингеренции кои беа бескорисни во контекст на проектот, но дефинитивно интересни како демонстрација на опасноста од нападот. Гранични рутери на големи компании со телнет, препратени http порти за дебагирање до внатрешен CRM со сите податоци, директен пристап до RDP од Windows XP на локалната мрежа и друг опскурантизам. Испадна вака Компромис со синџирот на снабдување според матрицата MITER.

Најдов и една смешна прилика да собирам писма од сообраќајот, вакво нешто. Ова е пример на готово писмо што отиде од нашиот клиент до SMTP-портата на неговиот клиент, повторно, без шифрирање. Извесен Андреј бара од својот имењак повторно да ја испрати документацијата и таа е поставена на облак диск со најава, лозинка и врска во едно писмо за одговор:

Ова е уште еден потсетник за шифрирање на сите услуги. Не се знае кој и кога конкретно ќе ги чита и користи вашите податоци - давателот, системскиот администратор на друга компанија или таков пентер. Молчам за фактот дека многу луѓе едноставно можат да пресретнат нешифриран сообраќај.

И покрај очигледниот успех, тоа не не приближи до целта. Се разбира, можеше да се седи долго време и да се извлечат вредни информации, но не е факт дека тие ќе се појават таму, а самиот напад е многу ризичен во однос на интегритетот на мрежата.

По уште едно копање во услугите, на памет дојде една интересна идеја. Постои таква алатка наречена 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, преку кои корисниците пристапуваа до глобалната ВЕБ, периодично кешираа статична содржина. Пресретнувајќи го сообраќајот, беше јасно дека тие работат деноноќно, бескрајно барајќи често користена статика за да се забрза прикажувањето на содржината за време на шпицот. Покрај тоа, BlueCoat имаше специфичен кориснички агент, што јасно го разликуваше од вистински корисник.

Беше подготвен Javascript, кој, користејќи Intercepter-NG, беше имплементиран по еден час ноќе за секој одговор со JS-датотеки за Blue Coat. Сценариото го правеше следново:

• Го одреди тековниот прелистувач од кориснички агент. Ако беше Internet Explorer, Edge или Chrome, тој продолжи да работи.
• Чекав додека не се формира ДОМ на страницата.
• Вметната невидлива слика во DOM со атрибут src на формата преображенски:8080/NNNNNN.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:

Во оваа ретка снимка можете да видите како Роскомнадзор им помага на пендерите

Ова беа првите месеци по познатото блокирање на „фан“ на Телеграм, кога цели мрежи со илјадници адреси незапирливо исчезнаа од пристапот. Стана јасно зошто притискањето не функционираше веднаш и зошто мојата „жртва“ не алармираше бидејќи почнаа да ја користат нејзината сметка за време на отвореното време.

Секој кој е запознаен со Citrix Netscaler замислува дека тој обично се спроведува на таков начин што на корисникот може да му се пренесе само интерфејс со слика, обидувајќи се да не му ги даде алатките за стартување апликации од трети страни и пренос на податоци, ограничувајќи ги на секој можен начин активностите преку стандардни контролни школки. Мојата „жртва“, поради неговата професија, доби само 1С:

Откако малку го прошетав интерфејсот 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 хашот на стандардниот локален администратор (кој одеднаш беше наречен Администратор) беше пристапен преку напад на „pas-the-hash“ до соседните VDI хостови, од кои имаше неколку стотици. Се разбира, нападот веднаш ги погоди.

Еве каде администраторите на VDI си пукаа двапати во нога:

• Првиот пат беше кога VDI машините не беа ставени под LAPS, во суштина ја задржаа истата локална администраторска лозинка од сликата што беше масовно распоредена на VDI.
• Стандардниот администратор е единствената локална сметка која е ранлива на напади со хаш-услуги. Дури и со истата лозинка, би било можно да се избегне масовен компромис со креирање на втор локален администраторски профил со сложена случајна лозинка и блокирање на стандардната.

Зошто има SSH услуга на тој Windows? Многу едноставно: сега серверот OpenSSH не само што обезбеди удобна интерактивна командна обвивка без да се меша во работата на корисникот, туку и прокси socks5 на VDI. Преку овие чорапи, се поврзав преку SMB и собрав кеширани сметки од сите овие стотици VDI машини, а потоа ја барав патеката до администраторот на доменот користејќи ги во графиконите BloodHound. Со стотици домаќини на располагање, го најдов овој начин доста брзо. Добиени се администраторски права на домен.

Еве слика од Интернет што покажува слично пребарување. Врските покажуваат кој е каде е администраторот и кој каде е логиран.

Патем, запомнете ја состојбата од почетокот на проектот - „не користете социјален инженеринг“. Значи, предлагам да размислиме колку сето ова Боливуд со специјални ефекти би било отсечено ако сè уште беше можно да се користи банален фишинг. Но, лично ми беше многу интересно да го направам сето ова. Се надевам дека уживавте во читањето на ова. Се разбира, не секој проект изгледа толку интригантно, но работата во целина е многу предизвикувачка и не дозволува да стагнира.

Веројатно некој ќе има прашање: како да се заштитите? Дури и овој напис опишува многу техники, од кои многу администраторите на Windows не ни знаат. Сепак, предлагам да ги погледнеме од перспектива на пробиени принципи и мерки за безбедност на информациите:

• не користете застарен софтвер (се сеќавате на Windows 2003 на почетокот?)
• не ги вклучувајте непотребните системи (зошто имаше веб-страница на уролог?)
• сами проверете ги лозинките за јачина на корисникот (инаку војниците... ова ќе го направат пестерите)
• немаат исти лозинки за различни сметки (компромис за VDI)
• и други

Се разбира, ова е многу тешко да се спроведе, но во следната статија ќе покажеме во пракса дека тоа е сосема можно.

Извор: www.habr.com