Сценарий для взлома. Разбираем типовые сценарии атак на корпоративные сети

INFO

Мы не будем раскрывать адреса ресурсов и имена сотрудников протестированных организаций. Однако описанные сценарии атак не привязаны к сфере деятельности: подобные недостатки защиты могут встретиться в любой отрасли и нанести значительный ущерб.

Преодоление периметра

Чтобы преодолеть внешний периметр, нарушитель должен получить доступ к узлу, подключенному также к внутренней сети, и иметь возможность выполнять на нем произвольный код. Уязвимости, которые чаще всего приводят к этому, можно поделить на шесть основных типов:

• недостатки управления учетными записями и паролями;
• уязвимости веб-приложений;
• недостатки фильтрации трафика;
• недостатки управления уязвимостями и обновлениями;
• плохая осведомленность пользователей в вопросах информационной безопасности;
• недостатки конфигурации и разграничения доступа.

В отдельных пентестах каждый из этих пунктов позволял достичь цели без других атак. Иногда для преодоления периметра мы комбинировали перечисленные методы, но это лишь повышало сложность атаки, а не предотвращало проникновение.

Сценарий 1. Подбор учетных данных

Интерфейсы управления и удаленного доступа

Протоколы удаленного доступа упрощают работу системного администратора и дают ему возможность управлять устройствами удаленно. Среди распространенных инструментов — Telnet, RSH, SSH и протоколы для удаленного подключения вроде RDP. Чаще всего администраторы используют для этого общедоступное ПО: Radmin, Ammyy Admin и подобные. Это позволяет внешнему нарушителю проводить атаки на подбор учетных данных.

Такая атака не требует никаких особенных знаний и навыков: в большинстве случаев достаточно ноутбука, программы для подбора учетных данных (например, Hydra) и словаря, которые можно без труда найти в интернете.

Атаку может затруднить фильтрация по IP-адресам. В таком случае нарушитель, скорее всего, найдет другие пути. Например, скомпрометирует иные узлы в сети и попробует развить атаку не со своего адреса, а со скомпрометированных узлов. Существуют и другие методы обхода фильтрации.

Нередко в качестве пароля от SSH и Telnet можно встретить комбинацию root:root, root:toor, admin:admin, test:test. В некоторых случаях доступ с максимальными привилегиями удается получить вообще без ввода пароля.

Другие статьи в выпуске:

Xakep #217. Сценарий для взлома

• Содержание выпуска
• Подписка на «Хакер»-60%

Для доступа по RDP используются локальные либо доменные учетные записи. Часто это Administrator:P@ssw0rd, Administrator:123456, Administrator:Qwerty123, а также гостевая учетная запись Guest с пустым паролем.

Рекомендации по защите. Для SSH следует использовать авторизацию по приватному ключу. В целом же мы рекомендуем настроить файрвол таким образом, чтобы ограничивать доступ к узлам по протоколам удаленного управления: разрешать подключения только из внутренней сети и только ограниченному числу администраторов. Кроме того, нужно внедрить строгую парольную политику, чтобы исключить саму возможность установить простые или словарные пароли. Если же необходимо администрировать ресурсы удаленно, советуем использовать VPN.

Интерфейсы администрирования веб-серверов и СУБД

Существуют и другие службы, доступ к которым позволит внешнему нарушителю получить полный контроль над узлом. В их числе базы данных и веб-серверы.

Если в случае с SSH и Telnet изначально требуется вручную задавать пароль, то СУБД и веб-серверы обычно идут с паролем по умолчанию. Как показывает практика, далеко не все администраторы меняют эти пароли, а многие изменяют учетные данные на столь же простые комбинации.

Примеры наиболее распространенных учетных данных, которые выявляются в наших тестах на проникновение:

• СУБД — sa:sa, sa:P@ssw0rd, oracle:oracle, postgres:postgres, mysql:mysql, mysql:root, различные комбинации с пустым паролем;
• для серверов Tomcat — tomcat:tomcat, tomcat:admin.

Через админку Tomcat Web Application Manager можно загружать файлы в формате архива с расширением war. Атакующий может загрузить не только веб-приложение, но и веб-интерпретатор командной строки и получить возможность выполнять команды ОС.

Доступ к базе данных тоже открывает широкие возможности — в том числе позволяет выполнять на сервере команды с привилегиями СУБД. Этого может оказаться достаточно для атаки на другие узлы сети.

К примеру, в старых версиях MS SQL Server продукт устанавливался в ОС по умолчанию с привилегиями NT AUTHORITY\SYSTEM, максимальными в Windows. Нарушитель, подобравший учетную запись СУБД, моментально получал полный контроль над сервером.

В актуальных версиях MS SQL Server этот недостаток учтен, привилегии СУБД по умолчанию ограниченны — NT SERVICE\MSSQLSERVER. Однако даже эти меры зачастую не обеспечивают должный уровень защиты.

Другой вариант развития атаки — эксплуатация уязвимостей в ОС. В одном из пентестов мы выяснили, что пользователь NT SERVICE\MSSQLSERVER обладает привилегиями SeImpersonatePrivilege, которые позволяют ему с помощью токена делегирования (impersonation-token) присвоить себе привилегии любого другого пользователя из перечня доступных (например, при помощи утилиты Mimikatz).

Рекомендации по защите. Администраторы должны тщательно следить за тем, какой уровень привилегий используют те или иные системы и пользователи, и по возможности назначать минимальные права.

Рекомендуем ввести строгую парольную политику и ограничивать доступ к СУБД и интерфейсам администрирования веб-серверов из интернета, разрешив подключение только из локальной сети с ограниченного числа компьютеров.

Если удаленный доступ к администрированию веб-сервера необходим, рекомендуем ограничить список IP-адресов, с которых возможно подключение, и оставить доступ только с администраторских компьютеров.

Сценарий 2. Эксплуатация веб-уязвимостей

Чтобы получить возможность выполнять команды ОС, далеко не всегда требуется подбор учетных данных для доступа к интерфейсам управления. Зачастую такую возможность дают уязвимости веб-приложений, развернутых внутри сети компании. Если веб-приложение используется как публичный ресурс (официальный сайт, интернет-магазин, новостной портал), значит, к нему обеспечен доступ из интернета. Это открывает немало возможностей для атак.

Среди наиболее опасных уязвимостей веб-приложений можно выделить загрузку произвольных файлов, внедрение операторов SQL и выполнение произвольного кода. Эксплуатация таких уязвимостей может привести к полной компрометации сервера.

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

Даже если на сервере настроена эффективная проверка загружаемых файлов, необходимо учитывать и конфигурацию самой системы. Следующий пример демонстрирует, как ошибка администратора может позволить нарушителю скомпрометировать ресурс.

В исследованном приложении была реализована проверка, которая запрещала загрузку файлов с расширением PHP. Мы выяснили, что на сервере используется уязвимая комбинация ПО и ОС, которая позволяет обойти данное ограничение. В частности, в конфигурации CMS Bitrix в файле /upload/.htaccess не было установлено ограничение на загрузку файлов с расширением pht. Этот формат файла исполняется в ОС семейства Debian и Ubuntu как файл формата PHP. Таким образом, уязвимая конфигурация сервера позволила загрузить веб-интерпретатор командной строки на сервер в обход установленных ограничений.

Другой распространенный вид атаки на веб-приложения — с помощью SQL-запроса. Это несложная техника, но назвать ее тривиальной уже нельзя. На скриншоте показан пример выполнения команды ID через внедрение операторов SQL в комбинации с эксплуатацией уязвимости подключения локальных файлов.

Для эксплуатации таких уязвимостей злоумышленник должен знать, как обходить фильтрацию файлов при загрузке их на сервер, и уметь писать SQL-запросы. Но такие знания могут и не потребоваться в том случае, если ограничения на загрузку файлов отсутствуют вовсе.

Рекомендации по защите. Помимо строгой парольной политики, рекомендуем ввести белые списки для проверки загружаемых на сервер файлов. Для защиты от эксплуатации уязвимостей кода приложения (внедрение операторов SQL, выполнение команд) необходимо реализовать фильтрацию передаваемых пользователем данных на уровне кода приложения. Кроме того, рекомендуем использовать межсетевой экран уровня приложения (web application firewall).

WWW

Больше деталей можно найти в специальных отчетах «Уязвимости веб-приложений» и «Атаки на веб-приложения».

Сценарий 3. Эксплуатация известных уязвимостей

Атаки на уязвимый протокол

Еще один пример использования недостатков фильтрации трафика — это атака на протокол отладки Java Debug Wire Protocol (JDWP), один из компонентов системы Java Platform Debug Architecture (JPDA). Этот протокол не обеспечивает аутентификацию и шифрование трафика, чем могут воспользоваться внешние нарушители, если интерфейс JDWP доступен из интернета. Злоумышленник может взять общедоступный эксплоит для выполнения команд ОС. Кроме того, служба, использующая JDWP, зачастую обладает максимальными привилегиями, что позволяет внешнему нарушителю за один шаг получить полный контроль над сервером. Ниже показан пример успешной атаки с использованием общедоступного эксплоита.

Моделируя атаку на сервер, мы загрузили файл exec.pl с backconnect-скриптом. Далее мы поменяли привилегии на исполнение этого файла. В результате запуска скрипта был получен интерактивный шелл, который позволял выполнять команды ОС для развития атаки.

Рекомендации по защите. Этот пример показывает, как можно преодолеть периметр даже при использовании сложных паролей и регулярном обновлении ПО. Отладочные интерфейсы не должны быть доступны из внешних сетей.

Атаки на уязвимое ПО

По нашей статистике, использование устаревших версий ПО — один из наиболее распространенных недостатков безопасности. Как правило, в рамках пентестов эксплуатация уязвимостей ПО, позволяющих удаленно выполнять код, не производится, так как подобные атаки (например, направленные на переполнение буфера) могут вызвать отказ в обслуживании систем. Для нарушителя это условие не только не будет помехой, но может оказаться его основной целью. Вот лишь некоторые распространенные примеры устаревших версий различных систем и их уязвимостей:

• Windows Server 2003 SP1, SP2 (CVE-2012-0002);
• nginx 1.3.11 (CVE-2013-2028);
• PHP 5.3.8, 5.3.28, 5.5.1 и множества других версий (CVE-2014-3515, CVE-2011-3379, CVE-2013-6420), ProFTPD FTP Server 1.3.3a (CVE-2011-4130, CVE-2010-4221), OpenSSH Server 4.3 (CVE-2006-5051, CVE-2006-5052). До сих пор можно встретить даже Windows XP с известной уязвимостью (CVE-2008-4250).

Часто эксплуатация таких уязвимостей требует от атакующего особых знаний и навыков, например для разработки собственного эксплоита. В то же время существуют и общедоступные, а также коммерческие эксплоиты, которые могут быть использованы «из коробки» или с минимальными изменениями для адаптации к конкретным условиям.

В ряде проектов мы продемонстрировали эксплуатацию критически опасной уязвимости Heartbleed (CVE-2014-0160). Если сервис поддерживает SSL-соединения или если на узле используется *nix-образная ОС, уязвимая версия библиотеки OpenSSL позволит читать участки памяти серверного процесса (в данном примере — веб-сервера). В таких участках памяти могут в открытом виде находиться критически важные данные: учетные данные пользователей, пользовательские сессии, ключи доступа и прочее. В результате проведения атаки и анализа участков памяти был, в частности, получен пароль пользователя.

Рекомендации по защите. Для предотвращения подобных атак рекомендуем своевременно обновлять ПО и устанавливать обновления безопасности для ОС. Кроме того, желательно не раскрывать версии применяемых систем — в частности, версию веб-сервера, которая может указываться в стандартных сообщениях об ошибках или в ответе HTTP.

Сценарий 4. Социальная инженерия

Социальная инженерия — один из наиболее распространенных методов целевых атак. Он сводится к эксплуатации недостатка у сотрудников опыта в вопросах безопасности. Нарушитель может выведать данные для доступа к ресурсам в телефонном разговоре или личной переписке.

Приведем пример социальной инженерии в телефонном разговоре с одним из работников банка (осведомленность персонала которого нам надо было оценить). Сотрудника выбрали для разговора по результатам первичной рассылки фишинговых писем. Это был один из тех получателей, кто не просто перешел по ссылке из письма, а еще и вступил в переписку с экспертом Positive Technologies, приняв его за администратора своей корпоративной сети.

Наш эксперт представился администратором и предложил решить проблему неработающей ссылки в почтовой рассылке. Телефонный разговор длился около четырех минут, и этого времени оказалось достаточно, чтобы добиться поставленной цели — узнать учетные данные для доступа к рабочей станции сотрудника и ресурсам домена.

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

Естественно, не все люди так доверчивы, и при таком подходе велик риск, что сотрудник заподозрит неправомерные действия и обратится в службу безопасности. Поэтому злоумышленники часто привлекают более сложные социотехнические методы, которые требуют специальной подготовки.

Например, для использования фишинговых сценариев злоумышленник должен зарегистрировать собственный домен и разработать ложную форму логина. Ему необходимо сделать фишинговый ресурс максимально приближенным по дизайну страницы к настоящему ресурсу, который привык видеть сотрудник. Атакующий также разрабатывает сценарии для определения версий ПО, используемого сотрудником, и последующей эксплуатации уязвимостей этого ПО.

Если нарушитель ставит целью заразить рабочую станцию трояном, ему необходимо узнать, какие системы защиты используются в компании, а для этого требуется дополнительная разведка. Все это существенно усложняет атаку. Однако, как показывает опыт наших пентестов и расследований реальных инцидентов, социотехнические атаки можно успешно провести в большинстве современных организаций. Именно такие атаки в последние годы стали первым шагом киберпреступников к проникновению в корпоративные сети банков, государственных и промышленных организаций.

Ниже приведен пример фишингового письма, которое специалисты Positive Technologies рассылали во время нескольких пентестов в 2016 году. В этом письме используется домен, который по написанию схож с реально существующим. Внимательный сотрудник может легко обнаружить подозрительный адрес отправителя. Однако, как показывает практика, далеко не все сотрудники замечают подмену. Кроме того, нарушитель может изменить адрес отправителя на реально существующий адрес одного из сотрудников, чтобы не вызвать подозрений. Загрузка приложенного файла и попытка распаковать архив в рамках пентеста приводили лишь к отправке информации о пользователе и его ПО на адрес, указанный в фишинговом письме. Однако в случае реальной атаки компьютер жертвы мог быть сразу заражен вредоносным ПО.

Во время одного из расследований инцидентов мы выявили похожий случай — проникновение в сеть банка с помощью вредоносного ПО. Вредонос был разослан по электронной почте в архиве, при этом рассылка фишинговых писем велась с адресов сотрудников партнерского банка, с которыми жертвы уже переписывались. Адреса были подделаны злоумышленниками, которые предварительно провели разведку и изучили специфику почтовой переписки сотрудников. Вероятно, атакам подвергся и партнерский банк.

Рекомендации по защите. Сотрудники сами могут выявить некоторую часть атак, проводимых методами социальной инженерии. Здесь важна бдительность: нужно всегда проверять адрес отправителя, не переходить по сомнительным ссылкам и не запускать приложенные к письму файлы, если нет уверенности в безопасности их содержимого. Кроме того, ни при каких обстоятельствах нельзя сообщать никому свои учетные данные, в том числе администраторам и сотрудникам службы безопасности.

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

Сценарий 5. Открытые данные

Этот метод сам по себе не является атакой, однако эксперты Positive Technologies нередко используют его для успешного преодоления периметра как минимум в качестве первого шага при реализации других атак.

Исследование страниц веб-приложений зачастую позволяет выявить множество ценной информации, доступной в открытом виде: учетные записи пользователей, версии ПО и серверов, адреса критически важных систем, конфигурационные файлы оборудования и в особых случаях даже исходные коды веб-приложений. Любой внешний нарушитель может получить доступ к ресурсам с возможностью загрузки произвольных файлов без каких-либо атак на систему, если выявит учетную запись, например для доступа к ресурсу по протоколу SSH, для подключения к СУБД или к интерфейсу администрирования веб-приложения.

В открытом доступе может найтись и доменная учетная запись. В рамках одного из пентестов это позволило нам получить доступ к беспроводной сети, из которой был возможен доступ к контроллерам доменов в ЛВС. В другом проекте такая учетная запись открыла путь к множеству корпоративных ресурсов компании, доступных из интернета, в частности к системе Jira (развитие данного вектора атаки описано в сценарии 6).

Следующий пример показывает, как злоумышленник может использовать исходный код приложения. В этом примере в открытом доступе на периметре сети были обнаружены файлы директории .svn. Для получения исходного кода внешний нарушитель мог использовать программы dvcs-ripper и Subversion.

Если внешнее тестирование на проникновение подразумевает моделирование действий злоумышленника, который проводит атаки без каких-либо дополнительных знаний об атакуемой системе (методом черного ящика), то, получив исходный код веб-приложения, нарушитель сможет провести анализ методом белого ящика, то есть обладая полным набором сведений о приложении. Для анализа кода используются как ручные средства, так и широкодоступные автоматизированные решения. Все это позволяет выявить максимально возможное число уязвимостей и подготовить эксплоиты для атаки.

При анализе полученных файлов мы установили, что в одном из них в открытом виде хранится учетная запись администратора веб-приложения. Кроме того, нашлись уязвимости, позволяющие читать файлы и загружать их на сервер — а это дает возможность получить полный контроль над ресурсом, как было продемонстрировано в описании предыдущих сценариев.

Рекомендации по защите. Администраторы систем должны следить за тем, какие данные раскрываются на страницах веб-ресурсов, и обеспечивать эффективное разграничение доступа к файлам и директориям на серверах, доступных из внешних сетей.

Сценарий 6. Выход из песочницы

На сетевом периметре организации, как правило, есть публичные сервисы — веб-приложения, доступные по протоколам HTTP и HTTPS. Однако некоторые компании размещают на периметре и корпоративные ресурсы, почтовые сервисы (OWA), порталы и другие системы.

Рассмотрим сценарий атаки, которая начиналась с получения доменной учетной записи в открытом виде с общедоступной страницы веб-приложения. В результате это привело к тому, что мы смогли подключиться к большому числу корпоративных ресурсов на периметре сети (см. сценарий 5).

Среди таких ресурсов была система Jira, при подключении к которой внешний нарушитель может получить список всех пользователей домена. В рамках пентеста мы выгрузили этот список и подобрали пароль к учетной записи одного из доменных пользователей. Он состоял из слова P@ssw0rd — одного из самых популярных в корпоративных сетях. Теоретически эта учетная запись могла быть подобрана напрямую — например, если взять этот пароль и перебирать имена пользователей, пока не будет выполнен вход. Именно такой метод используется при пентесте для подбора доменных учетных записей во избежание блокировки. Он не входит в описываемый сценарий атаки, но еще раз показывает, насколько важно уделять внимание парольной политике и безопасному хранению учетных данных.

Подобранную учетную запись мы применяли для подключения к еще одному из корпоративных ресурсов компании, доступных на сетевом периметре, — системе Citrix.

Компании широко используют Citrix для виртуализации и удаленного доступа к приложениям, рабочим столам компьютеров и серверов с любого устройства. Обладая доступом к такой системе, пользователь не должен получать возможность выйти из виртуализации и выполнять команды ОС непосредственно на сервере, где установлен Citrix. Однако существуют методы обхода песочницы, которыми часто пользуются нарушители.

Запустив в Citrix браузер Internet Explorer, нарушитель может использовать встроенную функцию — открытие файла. Если на сервере не настроено строгое разграничение доступа к файлам и директориям, эта функция браузера открывает доступ к файловой системе, в том числе к директории установки ОС. Остается запустить файл cmd.exe для выполнения произвольных команд. Аналогичный вектор атаки можно реализовать и с помощью другого ПО, в котором есть функция открытия файла.

Рекомендации по защите. Мы показали пример эксплуатации уязвимости, связанной с недостаточно эффективным разграничением доступа к функциям и файлам ОС. Используя прикладные программы, нарушитель может получить доступ к любым файлам на сервере. Это серьезная ошибка администрирования ресурса.

Для предотвращения таких атак следует пересмотреть вопрос о размещении корпоративных ресурсов на периметре сети. Если же без этого не обойтись, то нужно ввести строгую парольную политику, а также жесткое разграничение доступа к директориям и файлам ОС. Тогда пользователи таких систем, как Citrix, не смогут получить доступ к файловой системе сервера. У них не должно быть прав на исполнение файлов и доступа к директории установки ОС. Разграничивая доступ, следует придерживаться принципа минимальных привилегий. Кроме того, для запуска ПО в системе Citrix рекомендуется использовать защищенный протокол TLS с проверкой наличия корневого сертификата у клиента.

Получение контроля над КИС

Атаки на ресурсы внутренних сетей обычно проводятся от лица двух типов нарушителей — внутреннего, обладающего доступом к сетевой розетке на территории организации, либо внешнего, успешно преодолевшего сетевой периметр. Модель внутреннего нарушителя может меняться в зависимости от того, из какого сегмента сети развивается вектор атаки, а также в зависимости от уровня начальных привилегий атакующего.

Если для атак из интернета не требуется проходить дополнительную аутентификацию в сети (так как нарушитель уже получил определенный уровень привилегий на скомпрометированном сервере, находящемся в определенном сетевом сегменте), то внутреннему нарушителю необходимо каким-то образом получить логический доступ к локальной сети, а также привилегии на одном из внутренних ресурсов — если, конечно, нарушитель не сотрудник организации, который уже обладает такими привилегиями.

Сложность развития атак со стороны внутреннего нарушителя во многом определяется конфигурацией сети и сетевого оборудования. В первую очередь — сегментацией, фильтрацией сетевых протоколов, а также настройками защиты сети от подключения сторонних устройств. К сожалению, далеко не все организации обеспечивают надежный уровень защиты на уровне сети.

Как правило, корпоративные системы строятся на базе доменов Active Directory. Они удобны и позволяют централизованно управлять даже крупными распределенными сетевыми инфраструктурами. Однако ошибки администраторов и рядовых пользователей могут сделать AD уязвимой. Практика показывает, что слабые места чаще всего — это слабые пароли и недостаточная защита привилегированных учетных записей домена.

Самый простой и самый распространенный сценарий атаки на сеть на основе Active Directory — это комбинация двух несложных действий внутреннего нарушителя: получение привилегий локального администратора на узле сети и запуск утилит для взлома на скомпрометированном ресурсе с целью получения учетных записей пользователей.

Атакующий может использовать учетную запись локального администратора для получения паролей в открытом виде. Это возможно из-за слабости реализации single sign-on (SSO) во всех системах Windows, где есть поддержка этого механизма. Уязвимость существует из-за того, что подсистемы Windows wdigest, kerberos и tspkg хранят пароли пользователей с помощью обратимого кодирования в памяти операционной системы. Для проведения таких атак существует специальный инструментарий, который можно найти в свободном доступе (например, утилиты Mimikatz или WCE).

Повторяя эти шаги последовательно на ряде узлов ЛВС, нарушитель может добраться до того ресурса, на котором активна учетная запись администратора домена, и получить ее в открытом виде.

Два описанных дальше сценария различаются лишь методом получения привилегий локального администратора на первом шаге. Всего же мы рассмотрим семь наиболее распространенных вариантов атак. Восьмым сценарием можно считать эксплуатацию известных уязвимостей программ и ОС, но такие случаи менее интересны с точки зрения техники эксплуатации уязвимости (например, использование общедоступного эксплоита, как показано на рисунке ниже). Их мы в этой статье затрагивать не будем.

Сценарий 1. Подбор доменной учетной записи

В большинстве корпоративных сетей настроены парольные политики для учетных записей в домене, но далеко не всегда они эффективны. Зачастую ограничения позволяют задавать словарные комбинации. Например, уже упомянутый пароль P@ssw0rd формально обладает достаточной длиной и сложностью, чтобы удовлетворять условиям политики, но он есть в большинстве словарей популярных паролей и наверняка будет проверен нарушителем одним из первых. Словари позволяют подобрать и более сложные комбинации.

Часто администраторы задают и ограничения на количество попыток ввода неверного пароля, с последующей блокировкой учетной записи. Однако нарушитель может запустить подбор одного (или двух) паролей для целого списка логинов — если у него есть информация о них. Получить такие данные несложно: внутреннему нарушителю (сотруднику организации) достаточно сделать запрос к контроллеру домена либо проанализировать адресную книгу почтового клиента; внешний же нарушитель может изучить открытые источники в интернете (публикации компании, презентации, контактные данные с официального сайта) либо использовать недостатки защиты данных, хранящихся на внешних ресурсах организации.

Кроме того, изучив принцип создания логинов, нарушитель может составить словарь для подбора. Чаще всего принцип прост: первая буква имени и фамилия сотрудника (например, DOMAIN\AIvanov), инициалы и фамилия (DOMAIN\APIvanov) и прочие вариации на основе ФИО.

Часто у таких учетных записей есть права локального администратора на одном из компьютеров или на сервере. Это позволяет нарушителю подключиться удаленно (например, по RDP) и запустить софт для взлома.

Основной преградой для нарушителя в таких случаях становится антивирус, но часто он настроен недостаточно эффективно, чтобы противостоять атакам. В нашей практике такое встречалось чуть ли не в каждом проекте: либо антивирус вовсе не запрещает запускать утилиты для взлома, либо привилегии локального администратора позволяют отключить антивирус или добавить хакерский инструментарий в список исключений.

Даже если антивирус заблокирует утилиту и злоумышленник не сможет снять эту блокировку, остаются другие варианты для проведения атаки. Для обхода защиты нарушителю достаточно запустить утилиту с любого общедоступного ресурса в сети либо сделать дамп памяти процесса lsass.exe (например, утилитой procdump) и запустить Mimikatz уже на своем компьютере. Кроме того, есть версия этой утилиты на PowerShell, которая не определяется антивирусными системами как опасное ПО.

Проведя такую атаку, нарушитель получает учетные данные всех пользователей, которые аутентифицировались в ОС. Среди них могут быть как локальные администраторы других компьютеров, так и привилегированные учетные записи домена. Этот вектор атаки применяется для получения полного контроля над доменом.

Рекомендации по защите. Почти в каждом из пентестов нам удавалось успешно завершить этот сценарий. Минимизировать риск можно при помощи строгой парольной политики для всех пользователей домена, а также ограничив привилегии локальных пользователей на рабочих компьютерах и серверах, входящих в домен. Для привилегированных учетных записей рекомендуем использовать двухфакторную аутентификацию. При этом важно понимать, что двухфакторная аутентификация тоже подвержена атакам (см. сценарий 5).

Сценарий 2. Атаки на протоколы сетевого и канального уровней

Если подобрать учетные данные не удалось или если нарушитель не смог получить список идентификаторов пользователей домена, его следующий шаг — попробовать проанализировать протоколы, используемые в сети. В частности, он может проводить атаки методом «человек посередине» с целью перехвата трафика (например, если удастся реализовать атаку ARP Poisoning) либо атаки на протоколы NBNS и LLMNR с целью перехвата идентификаторов и хешей паролей пользователей.

При пентестах атаки на ARP проводятся только по согласованию с заказчиком, который, как правило, против такой демонстрации — слишком велика вероятность нарушить работу сети. К тому же атака ARP Poisoning хорошо известна, поэтому рассмотрим атаки на другие протоколы.

В результате атак типа «человек посередине» могут быть перехвачены значения Challenge-Response для пользователей домена. По этим значениям можно подобрать пароль пользователя, причем уже без доступа к системе.

Протоколы NetBIOS Name Service (NBNS) и Link Local Multicast Name Resolution (LLMNR) используются для получения IP-адреса узла в том случае, если такая запись отсутствует на DNS-серверах, или когда эти серверы по тем или иным причинам недоступны. Если защита этих протоколов отсутствует, то становятся возможными атаки LLMNR Spoofing и NBNS Spoofing.

Нарушитель, находящийся в одном сегменте сети с атакуемым узлом, может прослушать широковещательный трафик NBNS и LLMNR и подменить адрес узла, на котором атакуемый узел пытается авторизоваться. В случае успешной атаки злоумышленник сможет прослушивать и модифицировать трафик в сетевом сегменте, а также получать аутентификационные данные пользователей и с их помощью авторизоваться на других узлах сети.

Получив идентификаторы и хеши паролей пользователей, злоумышленник способен подобрать пароли по значениям хешей. Кроме того, нарушитель сможет задействовать логины пользователей для развития атаки по сценарию 1.

Завершающий этап атаки (в случае успешного подбора учетных данных) аналогичен сценарию 1 — подключение к узлам, на которых полученная учетная запись обладает привилегиями локального администратора, и последующий запуск специализированных утилит для взлома.

Рекомендации по защите. Если в перечисленных протоколах нет необходимости, то их следует отключить. Если же они нужны, то применять превентивные меры защиты — например, объединять системы, использующие один из этих протоколов, в отдельные сегменты сети. Методы защиты от атак ARP Poisoning хорошо известны: использовать статические ARP-записи на шлюзах, функции систем обнаружения атак (например, препроцессора arpspoof системы Snort) или утилиты, такие как arpwatch, а также использовать функции Dynamic ARP Inspection коммутаторов Cisco и другие.

Сценарий 3. Атака SMB Relay

Если в сети используются протоколы NBNS и LLMNR, это открывает возможность не только для атак с целью перехвата хешей паролей пользователей, но и для хорошо известной атаки SMB Relay. Этот метод позволяет нарушителю перехватить аутентификационные данные, передаваемые от одного узла к другому, в процессе обмена информацией NTLM Challenge-Response.

Принцип атаки прост: нарушитель слушает сетевой трафик и ждет, когда один из узлов инициирует подключение к другому узлу. Как только такой запрос обнаружен, нарушитель реализует атаку «человек посередине» (например, LLMNR Spoofing): перехватывает запрос на аутентификацию от обратившегося узла и передает его на атакуемый сервер. Этот сервер возвращает ответ — просьбу зашифровать некоторое сообщение с помощью своего хеша, после чего перенаправляет его на узел, запросивший подключение. Следом происходит перенаправление этого зашифрованного сообщения. Так как сообщение было зашифровано корректным хешем, атакуемый сервер отправит нарушителю разрешение на аутентификацию. Злоумышленник аутентифицируется на сервере, а узлу, запросившему аутентификацию, отправит ответ об ошибке подключения. Нарушитель может реализовать такую атаку и в отношении того же ресурса, который отправляет запрос на подключение.

Эта атака известна давно, и компания Microsoft еще в 2008 году выпустила бюллетень безопасности MS08-068 и соответствующий патч для Windows. На системе с патчем нарушитель не сможет провести атаку на тот же компьютер, если он инициирует подключение. Но возможность атаковать с помощью SMB Relay другие узлы в домене останется, если на них не реализована подпись SMB-пакетов — SMB Signing.

Простоту реализации атаки покажем на примере одного из наших пентестов. Анализируя трафик сети, мы выявили, что один из компьютеров периодически запрашивает адрес другого узла, после чего шлет на него HTTP-запрос с доменной учетной записью. С помощью утилиты Responder мы успешно атаковали выбранный нами узел сети, отправив запрос на подключение с того узла, который изначально инициировал запрос.

На атакованном сервере возможно выполнение команд с привилегиями того пользователя, чьи аутентификационные данные были перехвачены в рамках SMB Relay (в нашем случае привилегии оказались максимальными). В результате был получен полный контроль над сервером.

Вероятность реализации подобной атаки высока. В крупных сетевых инфраструктурах часто используются автоматические системы для инвентаризации ресурсов, установки обновлений, резервного копирования и других задач. Такие системы ежедневно подключаются к ресурсам домена и могут использоваться нарушителями для атак.

Рекомендации по защите. Для защиты от атаки необходимо реализовать подписывание SMB-пакетов (SMB Signing) на всех узлах сети, а также отключить протоколы NBNS и LLMNR. Кроме того, необходимо регулярно устанавливать актуальные обновления безопасности ОС.

Сценарий 4. Чтение памяти процесса

Для развития атаки в локальной сети нарушитель может использовать привилегии, полученные на первых шагах атаки (например, по сценариям 1, 2 или 3), либо у него уже могут иметься повышенные привилегии, если речь идет о недобросовестном сотруднике компании. К примеру, нарушитель, обладающий привилегиями локального администратора на узле, может сохранить дамп памяти процессов ОС. В общем случае достаточно привилегий того пользователя, от имени которого были запущены процессы.

В сценарии 1 приведен пример того, как может быть использован дамп процесса LSASS, а здесь мы рассмотрим другое применение этой атаки.

Для безопасного хранения паролей многие администраторы используют специализированные утилиты. В данном случае мы провели атаку, которая позволила получить ключ доступа к файлам программы PINs. В них хранились пароли от множества критически важных систем атакуемой организации. На рисунках ниже показано, как с помощью общедоступной утилиты procdump был получен дамп памяти процесса PINs.exe, а в самом дампе найден пароль a************1.

В результате атаки нарушитель получает список паролей и может использовать их для подключения к критически важным системам.

Рекомендации по защите. Для реализации атаки нарушителю необходим определенный уровень привилегий. Если процесс запущен от имени локального администратора, то защититься поможет ограничение привилегий пользователя ОС. Однако нарушитель сможет читать память тех процессов, которые запущены от имени такого пользователя (как показано в рассмотренном примере). Поэтому для защиты необходимо в первую очередь предотвратить несанкционированный доступ к ОС, для чего обязательна строгая парольная политика, регулярное обновление ПО и защита от подбора учетных записей.

Сценарий 5. Групповые политики

Этот сценарий атаки постепенно теряет популярность, однако по-прежнему встречается. В его основе — ситуация, когда администраторы используют файлы групповых политик для смены паролей от учетных записей локальных администраторов.

Зачастую привилегированные пользователи домена, создавая такие политики на контроллере домена (в директории sysvol), вносят учетные данные в файл групповой политики (что небезопасно). Пароль кодируется ключом AES, однако ключ шифрования общедоступен и опубликован на сайте msdn.microsoft.com. Таким образом, нарушитель, обладающий привилегиями пользователя домена, может получить учетные данные локальных администраторов на множестве узлов сети.

Вот как происходит расшифровка пароля.

1. dDPhfo*******************************ICtL64 — зашифрованный пароль. Справа к нему добавляются знаки равенства таким образом, чтобы длина полученной строки была кратна четырем.
   

   

2. Эта строка декодируется из Base64-представления.
   

   

3. Полученная строка расшифровывается по алгоритму AES с помощью ключа, доступного на сайте Microsoft.
   

   

   
   

   

4. Восстановлен пароль c******m.

Для развития атаки по этому сценарию у атакующего должен быть доступ к файлам групповых политик. Такие привилегии могут быть у пользователей домена, либо их можно получить по сценариям атак 1 и 2.

Рекомендации по защите. Такой механизм изменения паролей локальных администраторов широко применяется в корпоративных сетях, так как администратору не приходится подключаться к каждому из узлов, где необходима смена пароля. Рекомендовать в данном случае можно либо полный отказ от этого подхода, либо создание подобных политик только на ограниченное время, в которое совершается смена паролей, и удаление политик сразу же после выполнения операции. При этом необходимо принимать во внимание риски компрометации узлов сети.

Сценарий 6. Золотой билет Kerberos

Мы решили выделить эту атаку в отдельный сценарий из-за ее чрезвычайной опасности, хотя она требует первоначального получения соответствующего уровня привилегий. Атака основана на генерации билета доступа Kerberos пользователя на основе NTLM-хеша служебной учетной записи krbtgt и возможна из-за особенностей архитектуры протокола Kerberos и операционных систем Windows.

Протокол Kerberos базируется на ticket-системе, то есть на предоставлении билетов доступа к ресурсам доменной инфраструктуры. Нарушитель способен создавать golden ticket на получение доступа любого уровня привилегий и, соответственно, может обращаться к ресурсам домена с максимальными привилегиями.

Атака реализуема, только если у атакующего есть NTLM-хеш пароля krbtgt, получить который можно при наличии у атакующего актуальной резервной копии Active Directory либо привилегий в домене, которые позволяют сделать такую копию (например, администратора домена). В случае успешной атаки будет крайне сложно обнаружить дальнейшие действия злоумышленника, использующего аутентификацию по Kerberos, а смена паролей учетных записей, для которых были сгенерированы билеты доступа, не позволяет защититься.

Рекомендации по защите. В случае успешной компрометации системы развитие атаки можно предотвратить, только сменив пароль пользователя krbtgt, что сопряжено с перезапуском служб, использующих доменную аутентификацию. При этом стоит учитывать, что сама по себе смена пароля krbtgt не исключает возможности повторного получения атакующим NTLM-хеша пароля krbtgt, если у него сохранились первоначальные привилегии.

Во избежание подобных атак рекомендуем обеспечить защиту привилегированных учетных записей (в частности, тех, что позволяют проводить резервное копирование Active Directory), в том числе при помощи средств двухфакторной аутентификации, а также обеспечить защиту резервных копий службы каталогов. Кроме того, важно защитить рабочие станции и серверы от атак с использованием утилит для получения учетных данных в открытом виде, в частности Mimikatz.

Сценарий 7. Pass the hash и pass the ticket. Атака на двухфакторную аутентификацию

В примере выше мы советовали использовать двухфакторную аутентификацию для защиты привилегированных учетных записей критически важных систем — например, контроллеров домена. Однако это не означает, что двухфакторная аутентификация сама по себе полностью защищает от атак. Скорее, это один из необходимых шагов при построении комплексной защиты корпоративной сети. Следующий сценарий демонстрирует уязвимости механизма двухфакторной аутентификации в Windows.

Войти в Windows можно как по логину и паролю, так и при помощи смарт-карты. Администратор может настроить систему так, чтобы она запрашивала исключительно смарт-карту для доступа к ОС либо предоставляла пользователю выбор метода.

Принцип двухфакторной аутентификации подразумевает, что пользователь должен не только знать что-то (например, PIN-код или пароль), но и обладать чем-то (в данном случае — смарт-картой с установленным сертификатом). Только предъявив смарт-карту с корректным сертификатом и введя верный PIN-код, пользователь получает доступ к ОС.

Когда в конфигурации учетной записи домена устанавливается атрибут, отвечающий за аутентификацию по смарт-карте, этой учетной записи присваивается некоторый NT-хеш. Его значение вычисляется случайным образом и не меняется при всех последующих подключениях к ресурсам домена. Контроллер домена при каждой аутентификации отправляет этот хеш на узел, к которому подключается пользователь.

Уязвимость заключается в том, что злоумышленник может получить этот NT-хеш и использовать его для аутентификации методом pass the hash. В этом случае злоумышленнику уже не нужно обладать смарт-картой и знать ее PIN-код, то есть нарушается принцип двух факторов. А если учесть, что хеш постоянен, нарушитель получает возможность в любое время атаковать ресурсы домена с привилегиями скомпрометированной учетной записи.

Для того чтобы получить NT-хеш, злоумышленник может использовать результаты запуска утилиты Mimikatz на узлах сети в рамках атак по сценариям 1, 2 или 3.

На рисунке выше показан запуск Mimikatz на одном из узлов, а на следующем рисунке продемонстрирован результат успешной аутентификации методом pass the hash с полученным хешем пользователя. Этот пользователь входил в группу администраторов серверов, и для него была настроена аутентификация только по смарт-карте.

Кроме NT-хеша и пароля пользователя, злоумышленник может получить и PIN-код смарт-карты в открытом виде.

По сути, если злоумышленник может запускать утилиту Mimikatz на одном из узлов (непосредственно в ОС либо с использованием любого из подходящих методов обхода защиты), он получает возможность компрометировать учетные записи привилегированных пользователей домена — даже при использовании двухфакторной аутентификации. Механизмы авторизации в Windows построены таким образом, что, даже если нарушитель не сможет получить учетную запись администратора, он получит NT-хеш (генерируемый контроллером домена при использовании смарт-карты) либо билет Kerberos. Если NT-хеш не изменяется, не имеет срока действия и может быть использован на любом узле сети (в том числе на контроллере домена), то билет Kerberos выдается лишь на доступ к данному узлу на десять часов и может быть продлен в течение недели. Оба эти значения могут быть использованы злоумышленником для аутентификации в обход двухфакторного механизма для атак pass the hash и pass the ticket.

Рекомендации по защите. В Windows 10 реализована система Remote Credential Guard, которая призвана обеспечить защиту учетных записей при удаленном доступе к ресурсам. В рамках наших исследований мы еще ни разу не встречали Windows 10 в корпоративных сетях, а значит, исследование ее безопасности — дело ближайшего будущего. Использование Remote Credential Guard должно существенно повысить защищенность от атак методом pass the hash.

Заключение

Перечисленные сценарии атак — лишь часть тех техник, что используются в тестах на проникновение. Некоторые атаки на корпоративные сети реализуются намного сложнее, но основаны они на описанных здесь принципах.

Наш отчет призван обратить внимание администраторов систем, сотрудников подразделений информационной безопасности и их руководителей на то, что атаки на их ресурсы вполне предсказуемы. Каждый из описанных сценариев основан на эксплуатации наиболее распространенных уязвимостей, которые можно устранить, изменив конфигурации либо иными методами, требующими минимальных финансовых вложений.

Вот базовые принципы, которых мы рекомендуем придерживаться:

• использовать строгую парольную политику;
• защищать привилегированные учетные записи;
• повышать осведомленность сотрудников в вопросах ИБ;
• не хранить чувствительную информацию в открытом виде;
• ограничить число интерфейсов сетевых служб, доступных на периметре;
• защищать либо отключать неиспользуемые протоколы канального или сетевого уровня;
• разделять сеть на сегменты, минимизировать привилегии пользователей и служб;
• регулярно обновлять ПО и устанавливать обновления безопасности ОС;
• регулярно проводить тестирование на проникновение и анализ защищенности веб-приложений на периметре.

Напомним, что сложность компрометации ресурсов сильно зависит от того, является ли подход к защите комплексным. Дорогостоящие средства безопасности окажутся бесполезными, если пользователи и администраторы ресурсов применяют словарные пароли. В нашей практике было множество примеров, когда словарный пароль лишь одного пользователя позволял развить атаку до получения полного контроля над всей инфраструктурой корпоративной сети. А получив привилегии локального администратора на рабочей станции или сервере, нарушитель может развить атаку, даже несмотря на антивирус. Только при комплексном подходе к защите затраты на дорогостоящие средства безопасности будут оправданны.

WWW

• Расследование атак группы Cobalt;
• Отчет Positive Technologies об атаках в 2016-2017 годах и убытках, которые терпит крупный бизнес (PDF).