При проведении тестов на проникновение мы часто встречаемся с пренебрежением и халатным отношением к сайту компании. Для многих руководителей сайт является галочкой в репутационном портфолио. По мнению руководства и системных администраторов, сайт не приносит дохода и его взлом не несет больших репутационных рисков для компании, что является фатальной ошибкой. Самым ценным активом для любой компании является доступ во внутреннюю (локальную) сеть, в которой хранится вся ИТ инфраструктура предприятия.
Цель статьи - развеять миф о необязательности проверки сайта компании на уязвимости и показать, как взлом заброшенного сайта может дать билет злоумышленнику в локальную сеть.
Чем крупнее компания, тем больше у нее компьютерная локальная сеть и тем сложнее управлять ею. С целью облегчения работы по управлению системные администраторы настраивают корпоративную сеть на основе распространенного решения Active Directory (служба активного каталога). Это решение, действительно, упрощает управление ЛВС, но при этом несет в себе большие риски. Ключевым понятием в Active Directory является домен и контроллер домена.
1. Получение доступа к админке Bitrix
В качестве имени домена локальной сети, как правило, используется уже зарегистрированный домен сайта, почты и т.п. Возьмем для примера доменное имя target.ru. Зачастую в директории клиентского сайта доступна папка .git (рис. 1), которая отвечает за контроль версий исходного кода.
Наличие папки .git позволяет восстановить исходный код всего проекта, к примеру, с помощью инструмента GitDumper (рис 2).
В файлах проекта может находиться всё, что угодно: от скрытых файлов конфигураций до случайно оставленных резервных копий баз данных. Именно с резервной копией бд мы и столкнулись (рис 3).
Далее хеши паролей необходимо сбрутить. Например, через hashcat. С помощью найденных ранее имени пользователя и пароля был получен доступ к панели администратора Bitrix с максимальными правами (рис 4).
2. Исполнение команд на сервере
Встроенный функционал Bitrix позволяет внедрять пользовательский PHP код, который может привести к получению удаленного доступа к веб серверу (рис 5) и заливки web-shell (оболочки для выполнения команд).
3. Описание функционала AD, WPAD и autodiscover
Проверить наличие утечки можно проанализировав логи веб сервера. Если в файлах журнала имеются запросы следующего вида: /wpad.dat, /autodiscover.xml, /autodiscover/autodiscover.xml (рис 6.), то с большой долей вероятности у вас имеется уязвимость "утечка домена"- пользователи из внутренней сети пытаются получить файлы конфигураций из внешней.
Служба активного каталога обладает довольно широким функционалом по созданию групповых политик, управлению доступом и предоставлению доступа к различным сервисам. Контроллер домена в службе активного каталога представляет из себя DNS и DHCP сервер.
DHCP сервер предоставляет файл конфигураций wpad.dat (автоматическая настройка прокси сервера) и autodiscover (автоматическая настройка почтового сервера). Конечно, возможность использования автоматических настроек используется в системах по-умолчанию. При некорректной настройке доменных записей и фаерволла происходит "утечка домена". Почтовый клиент или браузер посылают запросы в глобальную сеть на домен target.ru по протоколу HTTP(S) с целью получить конфигурационные данные. Этим и может воспользоваться злоумышленник.
4. Перехват трафика через модификацию wpad.dat и использование mitmproxy
Сам по себе файл wpad.dat представляет из себя инструкцию для браузера на языке JavaScript, которая регламентирует доступы к ресурсам через прокси сервер на основании доменного имени или регулярного выражения. Клиентский браузер будет строго следовать полученным настройкам и все запросы полетят через указанный прокси сервер.
Злоумышленник, контроллируя содержимое файла wpad.dat, может установить адрес внешнего mitmproxy сервера для модификации или пассивного прослушивания всего исходящего из корпоративной сети трафика. К пример, перехват данных аутентификации hh.ru (рис 7) или чтение корпоративной почты (рис 8).
Далее, контроллируя весь трафик, существует возможность подмены исполняемых файлов (exe) и офисных документов (docx) на зловредные с содержанием исполняемого кода с целью заражения корпоративной сети предприятия.
5. Итоги и рекомендации
Халатность разработчиков и системных администраторов target.ru привела к компрометации корпоративной переписки. Настоящий злоумышленник заразил бы корпоративную сеть вредоносным ПО с дальнешейшим извлечением финансовой выгоды.
Легко сказать, что разработчики и администраторы обязаны защищать те или иные корпоративные ресурсы. Однако у этих специалистов совершенно другие функциональные обязанности и компетенции. Системный администратор - не специалист по информационной безопасности. Та же история с разработчиками.
Информационная безопасность - это комплекс мер, это процесс, это культура.
Так что же можно было сделать для предотвращения этой утечки?
Обязательно регулярно проводить внешние и внутренние пентесты. Тестирование на проникновение является необходимой мерой для предотвращения утечек;
Автонастройка системного прокси через WPAD используется по-умолчанию в WIN10. Необходимо отключать этот функционал, если он не нужен;
Необходимо запретить клиентам внутренней сети ходить на внешние ресурсы. Меньше прав - меньше проблем;
Необходимо контролировать целостность корпоративных ресурсов, а также наблюдать за логами доступа;
Необходимо настроить DHCP/DNS так, чтобы домен target.ru определялся, как ресурс во внутренней сети, а не во внешней.
Комментарии (20)
Firz
20.02.2022 11:27+2Легко сказать, что разработчики и администраторы обязаны защищать те или иные корпоративные ресурсы. Однако у этих специалистов совершенно другие функциональные обязанности и компетенции. Системный администратор — не специалист по информационной безопасности. Та же история с разработчиками.
Все таки «защищать»(хотя любой разработчик, который делает этот функционал, должен знать что нельзя использовать слабые алгоритмы хеширования, ну предположим что это осталось легаси 15 летней давности с MD5 каким-нибудь) и выкладывать в публичный доступ репозиторий с кодом и базой не одно и то же. Хуже могло быть только залитый готовый шел какой-нибудь или баннер на главной с логином/паролем от админки.
DikSoft
20.02.2022 11:54+2Поддерживаю. Если разработчики и системные администраторы вменяемые, то 1) будут использовать best practice решения 2) следовать политике информационной безопасности.
А если они творят такую дичь, как в статье ( база в гите, выставленные наружу тестовые среды в основном домене, репы, открытые снаружи всем ветрам) то, тут явно что-то не так с ИБ и с самими админами/разрабами. Либо с процессами.
DikSoft
20.02.2022 12:10+5Так что же можно было сделать для предотвращения этой утечки?
Разберём ваши рекомендации по пунктам:
1. Обязательно регулярно проводить внешние и внутренние пентесты. Тестирование на проникновение является необходимой мерой для предотвращения утечек;
- хорошая рекомендация, поддерживаю.
2. Автонастройка системного прокси через WPAD используется по-умолчанию в WIN10. Необходимо отключать этот функционал, если он не нужен;
- бить по рукам за такое сразу, отключать через GPO, верно.
3 .Необходимо запретить клиентам внутренней сети ходить на внешние ресурсы. Меньше прав - меньше проблем;
- а Вы точно ИБ компания? Может лучше дать людям работать, поработав сначала самим над настройками межсетевых экранов?
4. Необходимо контролировать целостность корпоративных ресурсов, а также наблюдать за логами доступа;
- Красиво сказано, но совершенно не раскрыто. Может быть речь про настройку и включение аудита и его мониторинг?
5. Необходимо настроить DHCP/DNS так, чтобы домен target.ru определялся, как ресурс во внутренней сети, а не во внешней.
- Использовать split DNS, либо если уж "так получилось", нормально настроить зоны пересылки
DikSoft
20.02.2022 12:15+1Если в файлах журнала имеются запросы следующего вида: /autodiscover.xml, /autodiscover/autodiscover.xml
- то кроме того, что кто-то ищет Exchange сервер с почтовым доменом, совпадающим с доменом сайта это ничего не значит.
mvv-rus
21.02.2022 00:18Контроллер домена в службе активного каталога представляет из себя DNS и DHCP сервер.
Неверно. Контроллер домена в AD совсем не обязательно представляет из себя сервер DHCP, и наоборот.Злоумышленник, контроллируя содержимое файла wpad.dat, может установить адрес внешнего mitmproxy сервера для модификации или пассивного прослушивания всего исходящего из корпоративной сети трафика.
И что? Mitmproxy, чтобы расшифровывать трафик соединения с сервером вынужен при установке соединения SSL/TLS предъявлять браузеру самопальный сертификат. И тут возникает вопрос — а почему это браузер должен доверять этому сертификату? Просто так браузер этому сертификату доверять не будет, сочтет его неверным, а для подключения к сайту с неверным сертификатом современные браузеры нужно довольно настойчиво уговаривать: пользователь этот процесс не заметить не может. А добавить эти сертификаты в список доверенных — это, вообще-то, требует отдельного взлома, контролировать wpad.dat для этого совершенно недостаточно.
Так что либо исправляйте статью, либо объясните, где именно я был не прав, либо ожидайте (его пока нет, но будет) минус к оценке за низкий технический уровень, вполне обоснованный.
lmsecurity Автор
21.02.2022 08:07-2Коллеги, давайте договоримся вести диалог в конструктивной форме. Если есть вопросы, то задавайте их корректно, пожалуйста. Впредь различного рода ультиматумы (объясняйте или поставлю минус), сомнения в компетентности или другие оскорбительные сообщения - будут игнорироваться. Мы не претендуем на звание "мистеров всезнаек" и можем где-то ошибаться. Все мы люди. Вы тоже где-то можете ошибаться. Помогите, подскажите, если мы где-то ошиблись - в нормальной форме. Все что мы пишем - основано на реальных кейсах. Ничего не выдумано именно с подобными вещами мы встречались в своей практике.
По поводу mitmproxy. Да, действительно сертификат используется самоподписанный. Никто и не говорил, что это стелс техника, но все же она работает. Когда браузеру подсовывается самоподписанный сертификат - он выдает диалоговое сообщение, мол "хотите или нет использовать сей сертификат". Как правило рядовые пользователи сети не обращают на это внимание (если сотрудников не обучали основам ИБ) и просто соглашаются использовать такой сертификат.
По поводу доменов типа some.local. Вы удивитесь но довольно часто компании используют локальный домен такой же как и внешний. Возможно вашей компании повезло и у них есть Вы. ) Но не каждый хороший сисадмин должен быть хорошим ИБшником равно как и наоборот. Системы усложняются и задача системного администратора следить за тем, чтоб стабильно работали сервисы обслуживающие бизнес процессы. Задача специалиста по ИБ следить за тем, чтоб на территорию не проникали злоумышленники. Опять же это все в общих чертах.mvv-rus
22.02.2022 04:04+1Если есть вопросы, то задавайте их корректно, пожалуйста.
Это были не вопросы, это были замечания.
Коли вы решили их проигнорировать — имеете право.Как правило рядовые пользователи сети не обращают на это внимание
Не обратить внимание на предупреждения крупными буквами сложно. И уж, в любом случае, считаю, что нужно было хотя бы упомянуть, что проблемы могут быть только в случае явного пренебрежения теми правилами безопасности в интернете, про которые твердят на каждом шагу. Иначе ваш текст вводит в заблуждение: преувеличивает реальную опасность.lmsecurity Автор
22.02.2022 08:49Вы удивитесь, но большая часть рядовых пользователей не обращают внимания на предупреждения и на автомате нажимают кнопку "Далее". Мы не пытались ввести в заблуждение никого. По нашей практике 30-40% процентов пользователей попадаются. Это достаточно большой процент. Но в какой-то степени вы правы. Позже доработаем статью и внесем ремарку.
mvv-rus
22.02.2022 16:32Вы удивитесь, но большая часть рядовых пользователей не обращают внимания на предупреждения и на автомате нажимают кнопку «Далее».
Не удивился бы, но там теперь (по крайней мере, в Edge и Firefox) недостаточно просто нажать кнопку «Далее»: там нужно нажать не самую очевидную кнопку — «Дополнительно», а потом ещё и нажать на небезопасную ссылку где-то на странице. Сделать это на автомате, если по первому разу — это надо очень упрямый автомат иметь.
Да и не по первому разу. Меня, к примеру, эти манипуляции при отладке свеженаписанного веб-приложения обычно достают настолько, что я не ленюсь добавлять нужный сертификат (он там чаще самоподписанный) в корневые доверенные.
DikSoft
Достаточно спорное утверждение. Гораздо чаще используются раздельные имена, IMHO.
mayorovp
От использования раздельных имён открывается отдельная уязвимость — кто-то может зарегистрировать этот самый "отдельный" домен, после чего "поймать" те же самые WPAD-запросы от какого-нибудь корпоративного ноутбука, оказавшегося за пределами домена.
DikSoft
Подскажите, как Вы себе видите регистрацию домена domain.local ?
mayorovp
Видимо, никак (а вот domain.lan может быть в будущем перехвачен). Если ноутбук оказался в вашей WiFi-сети, то можно перехватить DNS-запрос, но в таком случае ничего не помешает и HTTP перехватить без всяких настроек прокси.
С другой стороны, rfc6762 предписывает такие адреса резолвить через 224.0.0.251, что может открыть новый вектор атаки в каких-нибудь экзотических случаях. Кстати, а rfc6762 вообще кто-то следует?
DikSoft
Если внутри сети оказалось чужое устройство, то это печально. Особенно, если нет NAP/NAC или White-Listing. Поверхность атаки расширяется существенно. Но при грамотной настройке сетей и инфраструктуры ещё не смертельно.
rfc6762 - пришлось гуглить, даже не помнил про такой. Думаю, что .local это больше инерция и "традиция", чем осознанный выбор у многих.
mayorovp
Я писал не про чужое устройство в доменной сети, а про введённое в домен устройство, оказавшиеся в чужой сети.
DikSoft
Если к нему нет физического доступа, а есть только подключение к чужой сети, то скормить ему чужой фейковый доменный контроллер сложно. Так что данный риск сильно преувеличен, я думаю.
mvv-rus
del
Не туда
nuflin1
Согласен, у нас в компании имя домена тож различается.
mvv-rus
По наблюдениям с форумов MS Technet (я там бываю много и часто анализирую информацию о проблемах с AD, чтобы людям помочь), бывает очень по-разному. Вплоть до чужого домена —
под нормальным зарегистрированном доменом первого уровня (.ru, .com и т.д.), но организации, владеющей AD, не принадлежащим (не зарегистрированным или принадлежащим посторонним). Но чаще — таки да, используется домен второго уровня в фиктивной зоне верхнего уровня (.local, .loc и т.д).
А современная (AFAIK, но, по меньшей мере — недавняя) официальная рекомендация Microsoft — использовать домен, зарегистрированный на организацию, владеющую AD. Можно — тот же домен, что и для внешних ресурсов, организовав раздельное разрешение имен (split DNS).
Но следуют ей не только лишь все. Потому что, например, это создает трудности с доступом к своему же веб-сайту изнутри локальной сети, если сайт размещен где-то снаружи: контроллеры домена, если их специально не попросить так не делать (через настройку локатора имен контролеров домена в групповой политике), регистрируют на себя запись A с именем домена AD, и запросы на имя домена идут на них.