Охота на нежить: ускорение поиска в NetNTLMv1 без использования графических процессоров.

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

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

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

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

Протокол, который отказывается умирать

NetNTLMv1 (официально называемый протоколом «запрос-ответ» NTLMv1) — это устаревший протокол аутентификации Microsoft, используемый для проверки личности пользователя без передачи его фактического пароля по сети. NetNTLMv1 относится конкретно к сетевой полезной нагрузке, обмениваемой в процессе входа в систему.

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

• Слабая криптография (шифрование DES): NetNTLMv1 использует 56-битные ключи DES (стандарт шифрования данных) для шифрования. Поскольку 56-битное шифрование математически слабое, злоумышленник, перехвативший ответ NetNTLMv1 в сети, может легко расшифровать ключи DES и напрямую извлечь базовый хеш NT пользователя, независимо от длины или сложности пароля.
• Предсказуемые/заранее рассчитанные атаки: с помощью таких инструментов, как предварительно рассчитанные таблицы поиска (радужные таблицы), злоумышленник, контролирующий запрос к серверу, может за считанные секунды получить ответ клиента и расшифровать секретные ключи пользователя. Подробнее об этом позже…

Обнаружение NetNTLMv1 во время тестирования на проникновение может быть полезным, поскольку эта вредоносная программа часто встречается в средах Active Directory через устаревшие системы, неправильно настроенные хосты, устаревшее оборудование и иногда через контроллеры домена, к которым никто не хочет прикасаться.

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

Схема атаки будет знакома любому, кто занимался тестированием внутренних сетей:

1. Принудите целевого пользователя (в идеале, контроллер домена) к аутентификации.
2. Принудительное переключение на протокол NetNTLMv1 путем отправки запроса на сервер вместо использования более надежного протокола — PetitPotam, PrinterBug, Coercer и искаженное разрешение имен — все это ведет к одному и тому же результату.
3. С помощью статического запроса «1122334455667788» вам больше не нужно будет перебирать ответы методом грубой силы. Теперь вы можете просто найти ответ в интернете.

Всё это работает благодаря устаревшему 56-битному ключу DES из NetNTLMv1 (замененному расширенным стандартом шифрования (AES), который поддерживает 128-битные, 192-битные и 256-битные ключи). Путь выглядит следующим образом:

1. В ответе NetNTLMv1 принимается хеш NT жертвы.
2. Он дополняет (расширяет) хеш до 21 байта, разделяя его на три 7-байтовых сегмента.
3. Затем он использует каждый 7-байтовый сегмент в качестве ключа DES для шифрования того же 8-байтового серверного запроса.
4. Когда задача решена и известна, восстановление NT-хеша сводится к трем независимым задачам восстановления ключа DES по известному открытому тексту.
5. Третий сегмент тривиален: заполнение оставляет всего 2 байта реальной энтропии, создавая лишь 65 536 вариантов.
6. Современные процессоры восстанавливают их практически мгновенно, при этом первые два блока содержат полное 56-битное пространство ключей DES.

Вот тут-то и в дело вступают радужные столы.

Радужные столы

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

В 2021 году компания Mandiant опубликовала полный набор радужных таблиц NetNTLMv1 DES для этого сценария с фиксированной сложностью: 4096 файлов размером примерно по 2 ГБ каждый, охватывающих все пространство ключей 2^56 (всего около 9 ТБ).

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

Стандартные отраслевые инструменты, такие как Crackalack и классический rcrack, в значительной степени предполагают обязательное использование графических процессоров (GPU) для решения этой задачи. Это разумное проектное решение, но в крупномасштабных операциях тестирования время работы GPU часто является наиболее ценным доступным ресурсом. Когда поиск NetNTLMv1 монополизирует эти ресурсы на несколько часов, это создает узкое место для других вредоносных задач, которые действительно требуют ускорения с помощью GPU.

Налог на графические процессоры

Итак, действительно ли для выполнения поиска по радужной таблице требуется графический процессор?

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

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

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

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

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

Это поднимает очевидный вопрос: если значительная часть рабочего процесса зависит от операций ввода-вывода или оптимизирована для ЦП, нужно ли вообще выполнять поиск на графическом процессоре?

Побитовая нарезка DES, по 256 элементов за раз.

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

Решение заключается в побитовом разделении. Вместо того чтобы рассматривать регистр ЦП как единое 64-битное значение, побитовое разделение рассматривает его как несколько однобитных линий и выполняет несколько операций DES параллельно. Каждый S-бокс DES становится компактной сетью булевых операций, построенной из инструкций И, ИЛИ, Исключающее ИЛИ и НЕ-И.

Две дополнительные оптимизации делают этот подход практичным в масштабе:

• AVX2 расширяет размер среза: замена 64-битного слова на 256-битный вектор AVX2 увеличивает параллелизм в четыре раза, позволяя обрабатывать одновременно 256 операций DES вместо 64.
• Планирование ключей исчезает: в радужной цепочке ключи генерируются детерминированно. Вместо перестроения плана ключей DES для каждой операции, предварительно вычисленное отображение напрямую связывает каждый бит подключа с соответствующим битом исходного ключа. Поскольку генерация плана ключей составляла примерно 85% затрат в скалярной реализации, ее устранение обеспечивает существенное повышение производительности.

В совокупности эти оптимизации позволяют увеличить производительность до примерно 2,1 миллиарда операций DES в секунду на одном 64-ядерном процессоре EPYC — примерно в 15 раз быстрее, чем в исходной реализации. Процесс, который ранее занимал около 45 минут, теперь завершается примерно за три минуты, не задействуя ни одного цикла графического процессора.

Три этапа и бонус

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

1. На этапе предварительной обработки генерируется примерно 880 000 потенциальных конечных точек для целевого зашифрованного текста. Это этап, в значительной степени основанный на DES, и именно здесь побитовое разделение обеспечивает наибольший прирост производительности.
2. Поиск сканирует отсортированные таблицы в поисках совпадающих конечных точек. Поскольку таблицы сортируются предварительно один раз, поиск превращается в линейный потоковый проход по данным. На этом этапе основная нагрузка приходится не столько на криптографию, сколько на последовательное чтение с диска — именно для такого сценария и разработаны современные NVMe-накопители.
3. Функция Check берет небольшое количество совпадающих кандидатов и проходит по каждой цепочке, используя алгоритм DES с побитовым срезом, пока не будет найден правильный 7-байтовый ключ.

Есть и бонус. Третий блок NetNTLMv1 содержит всего 2 байта энтропии, что делает его достаточно малым для локального перебора практически мгновенно. Радужные таблицы не требуются. Графический процессор не требуется.

Идя широко

Этот набор столовых приборов большой, но обладает одним полезным свойством: он распадается на осколки естественным образом.

В нашем центре обработки данных работает несколько систем форм-фактора 4U, каждая из которых оснащена парой процессоров с поддержкой AVX2 и локальной копией своей части отсортированных таблиц v1 на NVMe-накопителе. Легковесная оболочка распределяет задачи по кластеру и собирает результаты.

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

Скорость расшифровки

Итак, насколько быстро эта методология может ускорить процесс расшифровки? В сквозном режиме на небольшом кластере двухпроцессорных 64-ядерных систем EPYC можно достичь следующих результатов:

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

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

Почему это важно в контексте наступательной безопасности

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

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

Что могут сделать защитники

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

Получите код: v1-nightshift

Хотите сами попробовать наш процесс? Для поддержки наших исследовательских и тестовых процессов NetNTLMv1 мы разработали v1-nightshift — инструмент поиска по радужной таблице на основе ЦП, предназначенный для разгрузки операций поиска NetNTLMv1 с графических процессоров.

Проект написан на языке C и зависит только от компилятора C и библиотеки pthreads. Он работает с общедоступными радужными таблицами NetNTLMv1 от Mandiant и включает в себя инструменты, необходимые для сортировки этих таблиц для эффективного поиска. Сборка осуществляется через make, с возможностью включения ускорения AVX2 с помощью параметра AVX2=1 на системах x86-64.

Поскольку исполняемые файлы зависят от архитектуры системы, проект следует собирать на той системе, где он будет работать.

GitHub: v1-nightshift

Читать полностью на источнике