История одного пентеста: тяжело ли взломать банк
/ 6
Всем привет.
Сегодня, дорогие читатели, я хочу расказать вам о пентесте, который мне довелось провести в одной из организаций-партнёров компании, в которой я сейчас работаю. Из соображений конфиденциальности не буду раскрывать название конторы, но скажу, что контора эта весьма приличных размеров (трудится в ней порядка 3000 человек), а кроме того, занимается она преимущественно банковскими операциями и как следствие, выполняет все нормы ЦБ и PCI DSS, не говоря уже о такой классике, как 152-ФЗ, 63-ФЗ и прочим подобным. Собственно, потому вторая часть названия данной статьи и говорит нам о взломе банков. В самом деле, согласитесь, интересно узнать, что может сделать рядовой бесправный сотрудник банка (или другой организации со сходным или меньшим уровнем информационной безопасности), имея только лишь доступ в корпоративную сеть и стандартные права доменного юзера? Поговорим об этом на конкретном примере проведённого мной теста на проникновение, показавшего весьма интересные результаты.
Итак, имеем некую большую организацию, обладающую не только огромной IT-инфраструктурой, но и управляющей приличными финансовыми потоками. В данной организации работает множество разнородных прикладных и системных сервисов, распределённых по инфраструктуре предприятия таким образом, что разобраться в ней в лучшем случае могут разве что сетевые админы, да и то каждый в своей сфере. Кстати, столь сложная инфраструктура там продиктована не столько реальными техническими нуждами, сколько совмещением принципа "изначально мы надеемся на малое и общую IT-архитектуру особо не продумываем, а потом по мере необходимости надстраиваем необходимое, вставляя обычно какие-нибудь костыли, с принципом "зато враг точно не разберётся в том, где тут что". :) Это не придумки, а реальный факт: "усиление" безопасности средствами роста сложности и костылей в инфраструктуре реально пользуется нынче популярностью. Как бы парадоксально это ни звучало. Да, под вышеупомянутыми надстройками понимаются не мелочи типа внедрения какой-нибудь Jira или чего ещё, а то очередную ферму виртуальных машин для нового процессинга, то накрутку Kerberos-аутентификации с новыми внутренним УЦ, то физически отдельный сегмент с каким-то каналом взаимодействия с DMZ, то что-нибудь ещё в этом духе.
Такими образом, проникнуть в какую-то зону инфраструктуры такой фирмы мало - нужно ещё понять, собственно, где ты оказался, что тут есть и куда дальше можно лезть. Любой пентестер сразу подумает о банальном сканировании ресурсов, но с учётом того, что в подопытной конторе стоят IPS-ки, да ещё и SIEM впридачу, а обнаруживать себя раньше времени ой как не хочется, ситуация становится чуть сложнее ожидаемой.
Итак, как же было дело. Начнём по шагам. Я - обычный доменный юзер, обладающий доступом в корпоративную почту (в т.ч. через внешний web-интерфейс: впоследствии это сыграет свою ключевую роль) и web-портал. Всё.
Шаг 1. Получаем права локального админа.
Первое, что удалось и что необходимо было сделать, - это раздобыть каким-либо образом права локального администратора (на машине с Win 7). Любой толковый IT-специалист знает десяток способов заполучить эти права: от хитроумных схем с повышением привиллегий в текущей сессии до брутальных загрузок с внешних носителей (если, конечно, позволяют политики BIOS). Я воспользовался наиболее доступным вариантом: загрузка по умолчанию стояла сразу только с внутреннего системного диска, дисковода не было вообще, я проверил BIOS - он оказался в свободном доступе - меняем загрузку на внешний носитель, в качестве которого выступила моя загрузочная флешка с заранее заготовленным на ней образом ERD Commander. :) Загрузившись в ERD, я тут же уничтожаю локальную антивирусную систему Касперского, т.к. она сильно будет мешать многим моим дальнейшим изысканиям (уничтожить до боли легко: переименовать или удалить системные директории KAV), а заодно меняем реестр целевой системы примерно таким образом:
- Запускаем regedit.
- Выбираем раздел HKLM, загружаем куст "..\Windows\System32\config\SYSTEM" (т.е. реестр целевой системы). Имя куста произвольное (возьмём "111").
- Заходим в HKLM\111\Setup
- Изменяем параметр CmdLine на cmd.exe (было <пусто>), дабы ОС при загрузке запустила нам cmd под правами системы.
- Изменяем параметр SetupType на 2 (было 0), дабы ОС подумала, что это первый запуск и стоит проделать то, что указано в п.4.
- Выбираем 111 и далее Файл->Выгрузить куст.
Теперь перегружаемся, меняем настройки BIOS на дефолтные, после чего ждём загрузки ОС, в процессе которой нам вылезет заветное cmd окно под заветными правами SYSTEM. Далее через net user врубаем системного админа и меняем ему пароль на свой (можно было и свою учётку создать, но это более заметно). Закрываем консоль. Всё, после дозагрузки системы мы имеем активного локального админа с известным паролем, что отрывает для нас безграничные возможности для дальнейшего сниффинга паролей / хешей заходящих локально на нашу машину. Более подробно о том, как получить права локального админа.
Шаг 2. Получаем права Desktop Support.
Что же происходило дальше? А дальше нужно было каким-то образом расширить свои права на зону не только одной локальной машины, а всей видимой части сети, входящей в мой пользовательский домен. Самый простой для этого способ - поставить кейлоггер на свою машину (вот зачем понадобилось вырубать антивирус) и методами социальной инженерии применить кого-нибудь в локальную ловушку. :) Я так и поступил: поставил кейлоггер под названием Elite keylogger: он работает как системный драйвер и после установки не палится ни одним АВ: главное, уставить, потом антивирус можно спокойно врубать, что я и сделал, дабы потом ко мне не возникло вопросов со стороны местной службы ИБ или того же сервис-инженера, на которого я нацелился (да, с учётом наличия в Elite keylogger режима тихой установки с предустановленными настройками по управлению машиной жертвы, штука весьма интересная). После чего пригласил сервис-инженера (чувак, который разбирается со всякими техническими проблемами) для настройки якобы неработающей у меня почты. Конечно, можно было изощриться и позвать сразу доменного админа, но для этого нужен был бы повод по-серьёзнее, да и не любят они нигде ходить по коридорам. Предварительно сетевые настройки аутлука были изменены таким образом, чтобы он не пахал. Заодно был выключен RDP, дабы ленивый сервис-инженер пришёл лично, а не подключился ко мне по RDP и не уладил всё так. В моём случае, правда, этого всё равно оказалось мало, т.к. кроме RDP управлять компом можно было ещё и через Lync, пришлось сломать ещё и его. В итоге, сервис инженер прибежал: ввёл имя-пароль, проблему быстро решил и ушёл. Пароль сервис-инженера, дающий админский удалённый доступ ко всем рабочим станциям в домене, у меня на руках. Как видите, ничего сложного.
Кстати, ещё немного по поводу антивируса. Как уже говорилось, касперского я потом успешно включил методом переименования его директорий на валидные, однако потом мне понадобилось снова его отрубать: для этого, как ни странно, не пришлось снова загружать ERD - достаточно было зайти в настройки службы KAV (просто отрубить её даже на правах админа, ясное дело, не получится) и поставить в ней загрузку от имени... Пользователя Гость. :) Всё, касперский наглухо умер. Быстро, легко, эффективно. И как-то несолидно для такого гиганта. Воскресить его, ясное дело, можно было ровно теми же манипуляциями, проделанными в обратном порядке. Часто это бывает необходимо, если в сети работает ещё и такая гадость, как NAC-служба. Кстати, в моей организации она была, но из-за частых жалоб на отсутствие срочно необходимого доступа, её вырубали или настраивали так криво, что лучше бы её и вовсе не было!
Шаг 3. Налаживание схемы безопасной работы.
Итак, права админа домена (точнее, условный их аналог) у меня есть. Что же дальше? Можно было подумать, что дальше я с улюлюканьем полез на компы финансовых руководителей, но нет: во-первых, как уже было сказано, их ещё нада было найти как внутри сети, так и узнать хотя бы имена компов; а во-вторых, SIEM и IPS не давали мне так спокойно творить в сети всё, что мне захочется и дабы не быть раскрытым в первый же день, нужно было предпринять ряд мер безопасности. Конечно, собственное нераскрытие не входит в обязательные правила успешного пентеста напрямую, но часто является необходимым условием для успешной реализации сложной длительной атаки, т.к. в случае провала будет ещё шанс. Что же я сделал?
Первым делом притащил из дома свой ноутбук, подключил его к сети через сетевой кабель соседа, воспользовавшись тем, что тот в момент моих злодеяний яростно поглощал пищу, и ввёл его в домен через права сервис-инженера, которые у меня были. Далее сетевой кабель от ноутбука я отключил и подключился с него к корпоративному wi-fi через всё того же сервис-инженера. Проблем с доступом не возникло, так как кривая NAC-служба по wi-fi пускала вообще всех! Далее возникла задача раздобыть себе другой комп для совершения злодеяний. Желательно какой-нибудь сервер, на котором постоянно логинится множество юзеров.
Немного пообщавшись с коллегами, я узнал о группе (одной из) прикладных админов, имеющих права на каких-то терминальных серверах. Их ФИО я узнал из web-портала, где можно было смотреть состав любого отдела компании. В конечном итоге мне нужно было найти NetBIOS-имя компа одного из этих админов, дабы потом получить доступ к терминалкам. Вооружившись прекрасной утилитой под названием psloggedon (из известного всем вин-админам набора PSTools), я со своего новоявленного в сети компании ноутбука стал вручную щадно сканировать имеющийся в наличии сетевой сегмент: понял распространение пользователей по сети. В итоге, понял, на каком этаже какой диапазон IP превалирует: на каждом этаже был свой мини-сегмент (не физический - просто правило). Таким образом, зная этаж и фамилию чувака, я написал простенький bat-скрипт, который бы просканировал IP из заданного мной диапазона (предварительно проверив их пингом на валидность) и остановился бы на заданном логине (логин я получал, как выход утилиты psloggedon). Через пару минут заветный IP, а с ним и NetBIOS-имя жертвы у меня было в руках.
Что же дальше? Надо ведь ещё получить пароль этого товарища. Для этого мне пригодилась другая утилита из набора PSTools, а именно - PSExec, позволяющая без зазрений совести исполнять в win-среде произвольный код от произвольного имени (имеются в виду, конечно, те имена, пароли от которых известны пентестеру :)). Но одного этого мало: ещё я воспользовался другой полезной утилитой под назанием Windows Credential Editor (или в просонародье WCE; в более широких кругах известна другая утилита под названием mimikatz: выполняет те же функции, но палится даже самыми отсталыми антивирусами). WCE тоже палится, потому я её запаковал UPX-ом, после чего закриптовал первым попавшимся мне рабочим криптором. После этого касперский на её срабатывание замолчал, что меня вполне себе устраивало. Ах да, забыл сказать главное: зачем же нам нужен WCE? За тем, что данная утилита умеет извлекать из оперативной памяти компьютера участок памяти виндового lsass-процесса, который хранит в нём пароли всех залогиненных юзеров. Большая и реально вредная в винде вещь: сделано это было для удобства авторизации на произвольных ресурсах сети (не на всех протоколах, как мы знаем, достаточно хешей), что в элитарных сообществах известно, как служба Single Sign On (SSO). Так вот, по дефолту SSO во всех win-средах включена, а многими она ещё и используется (реально удобно в крупных IT-инфраструктурах, обладающих разнородными сервисами). Для начинающих я недавно написал отдельную статью о том, как воровать пароли через кейлоггеры.
В итоге, через PSExec я залил WCE на комп жертвы и врубил его, получив пароль жертвы в открытом (!!!) виде. Даже не хеш - сразу пасс! Подождав обеденного времени, зашёл по RDP к жертве, посмотрел список терминалок, после чего зашёл на одну из наименее популярных у жертвы, но наиболее загруженных количественно терминалок и включил там в группу доступа нового юзера, пароль которого был предварительно украден вышеописанным способом (на компе первого попавшегося IP-шника). Всё. Теперь у меня был левый, не числящийся нигде ноутбук с wi-fi доступом в корпоративную сеть под именем левого юзера, с которого я мог подключиться к левой терминалке под левым аккаунтом и уже более менее безопасно конкретно для себя творить всё, что мне захочется.
Шаг 4. Разведка и получение доступов к критичным ресурсам сети.
Самое интересное. :) Псевдо-права доменного админа в наличии имеются, прикрытый тыл тоже. Как же действовать дальше? В первую очередь нужно узнать, где же в сети находится бухгалтерия и отдел кадров (данные сервисы были выбраны в качестве целевых).
Сделать это было не так уж сложно. Через web-портал я узнал имена юзеров из отдела кадров и бухгалтерии. Далее, воспользовался написанным ранее bat-скриптом-сканером, дабы найти имя компа сервис-инженера, пароль которого у меня был. Через 5 минут поисков скрипт выдал мне IP. Залогнившись по RDP на тачку сервис-инженера, отыскал по 1С базе выданного оборудования, имея ФИО, NetBIOS-имена компов юзеров из отдела кадров и бухгалтеров (дабы не сканировать всю сеть: диапазоны IP тех юзеров были мне неизвестны, да и сканирование в таком объёме точно не осталось бы незамеченным в сети). Далее, воспользовавшись уже известной связкой PSExec + WCE, узнал все интересующие меня пароли.
В итоге, в послерабочее время через RDP, полный доступ к базе отдела кадров, содержащей данные всех 3000 сотрудников компании. А вот с бухгалтерами пришлось сложнее. Во-первых, на их локальных машинах никаких баз и бух. программ в наличии не оказалось. Во-вторых, какие сервисы работают с финансами мне тоже было неизвестно. Надо было что-то делать. И вот что я придумал.
Да ничего особенного не придумал. :) Просто-напросто открыл через web-интерфейс внутенней почты ящики бухгалтеров, а также пары директоров финансового сектора и внимательно их изучил: там, как это ни странно, у директоров в принятых письмах обнаружил уведомления от веб-сервиса зарплатного проекта (на котором те отмечают премии своим сотрудникам). Я тут же авторизовался на этом сервисе под данными бухгалтера зарплатного проекта (пришлось слегка пробрутить бухгалтеров: они, как выяснилось, тоже обладают разными правами). В итоге, зарплаты всех 3000 сотрудников (в базе отдела кадров таких данных не было) ушли в PGP-бэкап на мой ноутбук. :) Но это ведь было не всё. Зарплаты можно было только смотреть, менять можно было только премии (от имён соответствующих руководителей). А хотелось ещё как-то заполучить доступ к системе управления финансовыми активами и уметь слать какие-нибудь платёжки! Вот для этого и понадобился последний - 5-ый шаг!
Шаг 5. Получение доступа к финансовым системам.
Как выяснилось спустя некоторое время, потраченное на изучение через почтовый веб-интерфейс (ох, как я ему благодарен за это :)) переписок руководителей разного ранга, финансовые системы находились в отдельной сетевой зоне и получить к ним прямой доступ не представляется возможным. Бухгалтера, ясное дело, обладают двумя машинами. Что же я сделал. Сломал сетевого UNIX-админа (он тоже обладает виндовым аккаунтом), у которого я в обеденное время обнаружил известный многим и не закрытый, видимо, по лени, KeePass (для тех, кто на бронетехнике: это менеджер паролей: системным админам (особенно UNIX) бывает крайне сложно запоминать десятки паролей от множества подконтрольных сервисов (root-ы на разных серваках, юзеры/root-ы на сетевом оборудовании и т.д.); для решения этой проблемы, да и для защиты от кейлоггеров, они используют вещи типа KeePass; иначе работать становится невозможно, если только админ не обладает феноменальной памятью или в конторе не трудится 5 человек). И вот эта феноменальная ошибка, а точнее, обыкновенная админская лень и позволила мне получить доступы к управлению сетевыми маршрутами и файерволами... Ну а дальше всё просто: пропиливаем себе сетевой доступ в нужный (финансовый) сегмент, после чего логинимся под аккаунтом бухгалтера (это ещё более ленивый класс персон: мало того, что пароли у них часто строятся по шаблону: <Имя><Фамилия><Какая-нибудь цифра> (в моём случае было ровно так!), так ещё и везде одинаковый! Правда, в моём случае для аутентификации в защищённом сегменте тоже использовался домен, точнее, другой домен, но с репликацией базы с основного). Вот и всё: заветный доступ в кармане.
Все обороты компании, все финансовые и прочие операции - всё как на ладони. Правда вот отправить платёж без токен-ключа не получалось, но как уже было сказано, обыкновенная человеческая лень часто сводит на нет огромные усилия службы информационной безопасности: часто, уходя на обед, бухгалтера оставляли свои токены воткнутыми в компы, а банковское приложение ДБО не проверяло, октуда идёт управление (удалённо или локально), в следствие чего можно было пополнить свои зарубежные счета, предварительно созданные на имена третьих лиц, 7-8-значной суммой. :)
Эпилог.
Вот такая вот реальная история произошла в одной из контор. К чему я её рассказал? Помимо очевидного интереса технических специалистов, она должна заставить задуматься ещё и руководителей компаний над такими вопросами, как контроль соблюдения мелочных, казалось бы вещей и правил политики информационной безопасности. Ведь, если бы за логами SIEM жёстко и постоянно следили, если бы не болтали направо-налево, кто к чему имеет доступ и если бы не оставляли свои токены воткнутыми на обед, а того и гляди на выходные, то многое из описанного выше потеряло бы всякий смысл.
А в общем и целом... Выше описанный сценарий может быть применим для атаки в 95-99% крупных компаний нашей необъятной страны. И не спасут вас никакие антивирусы (кстати, ещё, в процессе своих манипуляций, я раздобыл права админа антивирусной системы, но об этом как-нибудь в другой раз :)), IPS / IDS, DLP и SIEM. Может быть, доступ к финансам вы ещё худо бедно сможете как-то закрыть оргмерами или технически (а если нет, то украсть незаметно всё равно вряд ли что получится), то вот защитить постоянно ходящую по сети критичную информацию (а она может быть в обыкновенной служебной почте, и это могут быть клиентские базы, исходные коды, просто ноу-хау (идеи), за которые конкуренты иногда готовы заплатить 10 ваших годовых зарплат) вы, скорее всего, не сможете, так как не будете успевать своевременно следить за такими вещами, как скрупулёзная разработка, пересмотр и контроль (аудит) исполнения политики информационной безопасности (ведь реальная проблема была в отсутствии пароля на BIOS (хотя это меньшая из беда), во включённом SSO (а это уже беда) и обыкновенной лени сотрудников, в остальном система защиты работала на ура!). Об этих проблемах я в своё время писал здесь.
С уважением,
Лысяк А.С.
