От кариеса до пульпита. Заметки безопасника

От кариеса до пульпита. Заметки безопасника

В конце прошлой заметки я упомянул о теневой инфраструктуре. Сегодня поговорим о не совсем очевидной её части — учётных записях (УЗ). Они очень важны, так как фактически являются ключом для входа, в ряде случаев — напрямую из интернета. Рассмотрим несколько типичных проблем.

АКТУАЛЬНЫЙ ВЛАДЕЛЕЦ

Прежде всего, это банальное обеспечение того, чтобы у каждого аккаунта был указан актуальный владелец. «Ничейные» УЗ могут стать лёгкой добычей злоумышленников. Вот пример: в SOC поступил алерт из Azure о подозрительном входе в систему. Соответствующий аккаунт временно заблокировали, а в ходе расследования установили, что:

• попытка входа была успешной (то есть УЗ действительно была скомпрометирована);
• аккаунт был неиспользуемым (так как спустя несколько месяцев никто так и не попросил его разблокировать).

ACTIVE DIRECTORY

Второй аспект касается Active Directory: неплохо бы периодически проводить аудиты состояния учётных записей в ней. Пример: произошёл инцидент, в ходе которого была скомпрометирована УЗ администратора домена. Затем при очередном аудите AD было обнаружено, что у этой УЗ были изменены определённые параметры, что позволяло злоумышленнику подобрать пароль доменного администратора значительно быстрей обычного. Выявлено это было так: команда Get-Aduser сгенерировала дамп всех учётных записей AD, после чего было проанализировано поле User Account Control. Несмотря на большое количество пользователей, упомянутое поле имело всего порядка 5–6 уникальных значений, а подозрительный флаг присутствовал лишь у скомпрометированной УЗ.

Ещё пример: в ходе пентеста «белые шляпки» обнаружили, что пароли у нескольких сервисных учётных записей были указаны прямо в поле «комментарий» в Active Directory. Надо ли говорить, что после обнаружения этого факта взлом сети пошёл куда веселее…

ЛОКАЛЬНЫЕ УЗ

Ну и третий момент — это локальные учётные записи. Отследить их появление и использование значительно труднее, чем в случае централизованных аккаунтов. Да, они обладают меньшим «радиусом действия», но могут доставить немало головной боли. Один из примеров здесь — это практика использования сотрудниками техподдержки аккаунта локального администратора, который имеет одинаковое имя и пароль на всех ПК и серверах. Скомпрометировав любой хост и узнав этот пароль, злоумышленник автоматически получает административный доступ на любом другом хосте сети, куда ему удалось попасть. Одним из возможных решений проблемы называют LAPS; впрочем, организаций, сумевших это внедрить, я видел немного.

Другой пример: как-то раз я запросил у администраторов СУБД список пользователей, имеющих разрешение на обращение к определённой базе данных. Мне прислали список из нескольких сотен активных локальных УЗ, в котором фигурировали имена вроде с, test, victor и так далее. Кому все эти аккаунты принадлежат и какие из них можно отключить, никто, конечно же, не знал.

Поддержание порядка и обеспечение необходимого документирования — дело непростое, и о нём часто забывают под гнётом более приоритетных задач. До поры до времени это можно игнорировать — однако если пустить всё на самотёк, то рано или поздно инфраструктура деградирует настолько, что единственным вариантом останется создавать с нуля новую. Это подобно кариесу, который без должного лечения с большой вероятностью перерастёт в пульпит (а то и чего похуже). На мой взгляд, специалисты и особенно менеджеры ИБ должны постоянно напоминать руководству компании о рисках недостаточного документирования изменений.