Исследование от: Itay Cohen, Eyal Itkin
В последние месяцы наши группы по исследованию уязвимостей и вредоносного ПО объединили усилия, чтобы сосредоточить внимание на эксплойтах внутри вредоносного ПО и, в частности, на самих разработчиках эксплойтов.
Начав с одной рекации на вторжение, мы создали профиль одного из самых активных разработчиков эксплойтов для Windows, известного как «Volodya» или «BuggiCorp». К настоящему моменту нам удалось отследить более 10 (!)
Их LPE эксплойтов в ядре Windows, многие из которых на момент разработки были 0-day.
Предыстория
Наша история начинается, как и все хорошие истории, с случая реакции на вторжение. При анализе сложной атаки на одного из наших клиентов мы заметили очень маленький 64-разрядный исполняемый файл, который был запущен вредоносной программой.
Образец содержал необычные отладочные строки, указывающие на попытку эксплуатации уязвимости на машине жертвы. Что еще более важно, в образце был оставшийся путь PDB, который четко и ясно декларировал цель этого двоичного файла:
Это заинтриговало наc, и мы решили копнуть глубже.
Реверс-инжиниринг эксплойта был довольно простым. Бинарный файл был маленьким, и отладочные сообщения указывали нам путь. Он использовал уязвимость use after free (UAF) в CreateWindowEx, чтобы повысить привилегии родительского процесса.
Мы быстро кое-что заметили: казалось, что эксплойт и само вредоносное ПО были написаны разными людьми. Качество кода, отсутствие обфускации, PDB и временных меток - все это указывало на сделаный нами вывод.
Распостранение эксплойта
Мы склонны смотреть на людей, стоящих за конкретным семейством вредоносных программ, как на одно целое. Легче представить, что каждый компонент был написан одним человеком, командой или группой.
По правде говоря, создание продвинутого вредоносного ПО национальными государствами или преступниками требует участия разных групп людей с разными навыками. Организация кибершпионажа национального государства, вероятно,
будет иметь сотни или даже тысячи сотрудников в различных группах и отраслях. У каждого сотрудника в организации своя роль, отлаженная благодаря специальной технологической подготовке и многолетнему опыту.
В такой организации рабочая нагрузка по написанию общих компонентов распределяется между специализированными командами, при этом разные группы отвечают за разные составляющие атаки:
первоначальный доступ, сбор конфиденциальных данных, боковые перемещения и многое другое.
Организация, цель которой - встроить модуль эксплойта в свое вредоносное ПО, не может полагаться только на разработчиков вредоносного ПО. Обнаружение уязвимости и ее эксплуатация, скорее всего, будет выполняться определенными группами
или отдельными лицами, которые специализируются на конкретной роли. Разработчики вредоносных программ, со своей стороны, не заботятся о том, как это работает за кулисами, они просто хотят интегрировать этот модуль и покончить с этим.
Чтобы такое разделение труда работало, обе команды должны согласовать некий API, который будет мостом между различными компонентами. Этот интеграционный API не является уникальным для государственных субъектов,
но является обычным явлением на «свободном рынке» эксплойтов. Будь то подпольные форумы, брокеры, использующие эксплойты, или наступательные кибер-компании, все они предоставляют своим клиентам инструкции о том,
как интегрировать эксплойт в свои вредоносные программы.
По сути, эта точка интеграции является ключевым аспектом, на котором мы хотели бы сосредоточиться в нашем исследовании. Предполагая, что авторы эксплойтов работают независимо и распространяют свой код/двоичный модуль только авторам
вредоносных программ, мы решили сосредоточиться на них. Анализируя эксплойты, встроенные в образцы вредоносных программ, мы можем больше узнать об авторах эксплойтов, надеясь провести различие между ними, изучив их привычки
программированияи и другие следы, оставленные в качестве ключей к их личности, при распространении их продуктов среди их коллег, пишущих вредоносное ПО.
Определение разработчика эксплойта
Вместо того, чтобы сосредотачиваться на всей вредоносной программе и искать новые образцы семейства вредоносных программ или участников, мы хотели предложить другую перспективу и решили сосредоточиться на этих нескольких функциях,
написанных разработчиком эксплойта. Получение этого небольшого 64-битного двоичного файла из случая реагирования на вторжение казалось многообещающим началом.
Бинарный файл не делал ничего, кроме использования CVE-2019-0859, и не был основан на исходном коде или POC, которые были доступны в паблике. Он стал для нас отличным кандидатом на поиск следов, так как исполняемый файл был доработан из кода,
написанного кем-то ещё, кроме автора эксплойта. Более того, исполняемый файл был отделен от основного двоичного файла вредоносного ПО, что заставило нас поверить, что этот эксплойт не был разработан темиже разработчиками что и вредоносное ПО.
С этой надеждой мы решили найти больше эксплойтов, написанных тем же автором.
Мы начали с сбора простых артефактов из уже имеющегося двоичного файла: строк, внутреннего имени файла, временных меток и пути PDB. Сразу пришел первый результат - 32-битный исполняемый файл, который полностью соответствовал
64-битному образцу. В частности, как показали их временные метки и встроенный путь PDB, они были скомпилированы вместе, в одно и то же время и из одного исходного кода. Теперь, когда у нас были эти два образца, мы смогли опеределиться с тем,
что нам следует искать.
Чтобы идентифицировать автора этого эксплойта, мы cосредоточили наше внимание на следующем:
Помня об этих свойствах, мы оглянулись на два имеющихся у нас образца и отметили некоторые артефакты, которые мы считали уникальными. Несмотря на то, что у нас было только два небольших двоичных файла (которые по сути были одинаковыми),
мы смогли создать правила поиска, чтобы найти больше образцов, написанных этим разработчиком. К нашему удивлению, нам удалось найти их больше, чем мы ожидали.
Один за другим начали появляться десятки образцов, и с каждым из них мы улучшали наши правила и методики охоты. Тщательно проанализировав образцы, мы смогли понять, какие образцы эксплуатировали какие CVE,
и на основе этого создали временную шкалу, чтобы понять, был ли эксплойт 0-day или 1-day. это было реализовано на основе patch-diffing и аналогичных методов.
На данный момент у нас было более 10 CVE, которые мы могли отнести к одному разработчику эксплойтов, основываясь только на нашей методике снятия следов и без дополнительных аналитических данных.
Позже из публичных сообщений стало известно имя нашего целевого продавца эксплойтов: Володя (он же Володимир), ранее известный как BuggiCorp. Похоже, что мы были не единственными, кто отслеживал этого продавца эксплойтов,
поскольку Касперский несколько раз сообщал о них некоторую соответствующую информацию. Кроме того, ESET упомянул некоторые инкриминирующие следы Володи в своем выступлении на VB2019 о Buhtrap.
По словам Касперского, Володя впервые попал в заголовки под их ником BuggiCorp, когда они объявили о продаже Windows 0-day на известном форуме Exploit[.]in, со стартовой ценой 95 000 долларов. С годами цена росла, и некоторые из их 0-day
эксплойтов для Windows LPE продавались по цене до 200 000 долларов. Как было опубликовано в отчете Касперского и позже подтверждено нами, Володя продавал эксплойты как преступному ПО, так и группам APT.
Подробнее о его клиентах мы поговорим в разделе «Заказчики».
Эксплойты нашего подопечного
Хотя некоторые из наших первоначальных правил охоты нуждались в некоторой корректировке, даже немедленные результаты, которые мы получили, были довольно неожиданными. После дополнительной калибровки нам удалось найти множество примеров,
все из которых были эксплойтами Local Privilege Escalation (LPE) в Windows. Из этих образцов мы смогли идентифицировать следующий список CVE, которые использовались нашим субъектом.
Примечание:
При классификации эксплойтов мы выбрали консервативный подход при принятии решения о том, использовалась ли данная уязвимость как 0-Day или 1-Day. Если другие поставщики средств безопасности приписали эксплойт в условиях дикой
природы нашему подопечному, то это был 0-day. Если мы нашли достаточно доказательств того, что один из наших образцов действительно является распространяющимся в дикой природе эксплойтом, как это было описано поставщиком в их отчете,
мы также отметили его как таковой.
Во всех остальных случаях мы помечали уязвимость как 1-day, предпочитая иметь нижнюю границу отсчета 0-day вместо того, чтобы ошибочно превышать значения.
СVE-2015-2546
Тип: 1-day
Описание: Use-After-Free в
0-day репорт: FireEye
Был найден в следующих вредоносных ПО: Ursnif, Buhtrap
В наших сэмплах эксплойтов используется техника формирования памяти, отличная от описанной в первоначальном отчете: spraying Windows вместо Accelerator Tables. Кроме того,наш самый ранний и самый базовый пример эксплойта содержит
следующий путь PDB, предполагающий, что автору уже известен CVE-ID для этой уязвимости: «C:\…\volodimir_8\c2\CVE-2015-2546_VS2012\x64\Release\CmdTest. .pdb»
СVE-2016-0040
Тип: 1-day
Описание: Неинициализированный указатель ядра в
0-day репорт: N/A. Не был использован как 0-day
Был найден в следующих вредоносных ПО: Ursnif
Этот эксплойт использовался в единственном образце, который также содержал ранее описанный эксплойт для CVE-2015-2546. Этот эксплойт выбран, если целью является версия Windows более ранняя, чем Windows 8.
В противном случае используется CVE-2015-2546.
СVE-2016-0167
Тип: 0-day
Описание: Use-After-Free в
0-day репорт: FireEye.
Был найден в следующих вредоносных ПО: PUNCHBUGGY
Наши образцы эксплойтов идеально согласуются с техническим отчетом об эксплойте в дикой природе.
СVE-2016-0165*
Тип: 1-day
Описание: Use-After-Free в
0-day репорт: Обнаружена Kaspersky
Был найден в следующих вредоносных ПО: Ursnif
Это интересный случай. 0-Day нашего подопечного (CVE-2016-0167) был исправлен Microsoft в апреле 2016 года. Этот же патч также исправил CVE-2016-0165, который также использовался в дикой природе. В поисках новой уязвимости,
которую можно было бы использовать, наш субъект, вероятно, исправил исправления Microsoft и обнаружил уязвимость, которую они считали исправленной 0-Day. Эта уязвимость происходит из исправленной функции,
использованной в их предыдущей уязвимости:
*Из их образцов эксплойтов для этой уязвимости у нас есть несколько указаний на то, что либо автор эксплойта, либо, по крайней мере, их клиенты были уверены, что им продали эксплойт для CVE-2016-0165. Печальная правда в том,
что после анализа эксплойта мы можем сказать, что эксплуатируемая уязвимость отличается.
Эта путаница, вероятно, связана с тем, что Microsoft выпускает одно исправление, которое устраняет несколько уязвимостей, и только они имеют полное соответствие между каждым исправлением кода и выпущенной для него CVE.
СVE-2016-7255
Тип: 0-day
Описание: Повреждение памяти в
0-day репорт: Отмечено Google, технический отчёт от TrendMicro
Был найден в следующих вредоносных ПО: Был исползован APT28[они же Fancy-Bear, Sednit], позже использован Ursnif, Dreambot, GandCrab, Cerber, Maze
Наши образцы эксплойтов идеально согласуются с техническим отчетом об эксплойте в дикой природе. Этот конкретный эксплойт позже широко использовался различными организациями-вымогателями. Кроме того, мы видели и другие эксплойты для этой конкретной уязвимости, которые были проданы как 1-Days другим участникам программ-вымогателей.
Примечание: У нас есть несколько косвенных доказательств того, что именно этот 0-day был упомянут BuggiCorp в знаменитой рекламе, размещенной на форуме Explot[.]in в мае 2016 года.
СVE-2017-0001
Тип: 1-day
Описание: Use-After-Free в
0-day репорт: N/A. Не был использован как 0-day
Был найден в следующих вредоносных ПО: Был использован Trula, позже Ursnif
Используется как 1-day в операциях, приписываемых Turla (FireEye).
СVE-2017-0263
Тип: 0-Day
Описание: Use-After-Free в
0-day репорт: ESET
Был найден в следующих вредоносных ПО: Был использован APT28[они же Fancy-Bear, Sednit]
Наши образцы эксплойтов идеально согласуются с техническим отчетом об эксплойте в дикой природе.
СVE-2018-8641*
Тип: 1-Day
Описание: Двойное Освобождение Памяти в
0-day репорт: N/A. Не был использован как 0-day
Был найден в следующих вредоносных ПО: Magniber
Опять же, определение использованных 1-day обычно сложнее, чем определение 0-day. На этот раз мы не смогли найти ни одного примера, который мог бы намекнуть на уязвимость, которую, по мнению актера, он использовал.
*Мы определили, что эта конкретная уязвимость была исправлена Microsoft в декабре 2018 года. После сканирования списка уязвимостей, которые были устранены в этом исправлении, мы почти уверены,
что Microsoft пометила эту уязвимость как CVE-2018-8641, но мы не можем знать быть уверенны.
Обновление: 24 июня 2020 года Касперский опубликовал в своем блоге анализ эксплойтов, распространяемых с помощью эксплойт-кита Magnitude. В своем сообщении в блоге Касперский проанализировал эксплойт LPE,
использованный Magniber, приписал его Володе и оценил, что это, вероятно, CVE-2018-8641. Этот независимый вывод от имени Касперского подтверждает нашу первоначальную оценку.
СVE-2019-0859
Тип: 0-day
Описание: Use-After-Free в
0-day репорт: Kaspersky
Был найден в следующих вредоносных ПО: Используется как отдельный компонент для внедрения или загрузки. Мы не могли связать это с каким-либо конкретным APT / вредоносным ПО.
Наши образцы эксплойтов идеально согласуются с техническим отчетом об эксплойте в дикой природе. Наше исследование началось с одного образца эксплойта, который был обнаружен в сети клиента. В одном из примеров, которые мы нашли позже,
мы могли видеть эту чистую строку PDB:
СVE-2019-1132*
Тип: 0-day
Описание: NULL указатель в
0-day репорт: ESET
Был найден в следующих вредоносных ПО: Был использован Buhtrap
* У нас есть несколько причин полагать, что это был еще один эксплойт 0-Day от Володи, поскольку многие технические детали в отчете соответствуют их типичным способам эксплуатации. Кроме того, эксплойт сообщил, что в него встроен следующий
путь PDB:
СVE-2019-1458
Тип: 1-day
Описание: Повреждение памяти при переключении окон
0-day репорт: Kaspersky (Простой Отчёт, Более Детальный)
Был найден в следующих вредоносных ПО: Был использован WizardOpium
Наш эксплойт не соответствует техническому отчету об эксплойте в дикой природе. Кроме того, в своем подробном отчете «Лаборатория Касперского» отметила, что «также интересно, что мы обнаружили еще один однодневный эксплойт
для этой уязвимости всего через неделю после патча, что указывает на простоту использования этой уязвимости». И действительно, наша выборка датирована 6 днями после первоначального отчета Касперского.
Итоги по уязвимостям
Вот таблица, в которой перечислены перечисленные уязвимости:
Следы автора
Теперь, когда мы обнаружили более 10 различных эксплойтов Володи, мы можем рассмотреть их более подробно и ознакомиться с его привычками. С самого начала нам было ясно, что у нашего подопечного, вероятно, есть простой шаблон,
который они развертывают для различных эксплойтов, так как поток функций каждого эксплойта и даже порядок различных функций идентичен в большинстве эксплойтов.
В этом разделе мы описываем набор ключевых характеристик, которые отражают различные варианты реализации, выбранные Володей при создании шаблона эксплойта. Мы сравниваем их реализацию с реализацией другого автора эксплойтов,
известного под ником PlayBit. Путем этого сравнения мы стремимся очертить широкий спектр вариантов реализации, которые присутствуют в каждой части эксплойта,
делая набор вариантов реализации каждым автором уникальной «подписью» их образа мышления и работы.
PlayBit (a.k.a luxor2008)
Используя ту же технику, которую мы использовали для поиска эксплойтов Володи, нам удалось отследить 5 эксплойтов Windows LPE 1-Day, написанных PlayBit, в дополнение к другим инструментам, которые автор продавал на протяжении многих лет.
Мы начали с одного образца CVE-2018-8453, который используется программой-вымогателем REvil, и использовали уникальные отпечатки пальцев PlayBits для поиска новых эксплойтов.
Мы обнаружили следующие 1-day LPE эксплойты для Windows, реализованные этим автором:
а скорее являются уязвимостями в разных сервисах и, как таковые, имеют разную структуру.
Примечание: Более глубокий анализ PlayBit и различных эксплойтов, которые они разработали и продали, будет опубликован в следующем сообщении в блоге.
bool elevate(int target_pid)
API во всех примерах эксплойтов Володи всегда один и тот же. Независимо от того, был ли он встроен в образец вредоносного ПО или был отдельным POC,
эксплойт имел единственную функцию API со следующей сигнатурой:
Сам эксплойт не включает никаких функций для внедрения шелл-кода в другой процесс или чего-либо подобного.
Он предоставляет системные привилегии желаемому процессу, не принимая в качестве аргумента ничего, кроме его PID.
Sleep(200)
Самое первое, что делает функция
Не совсем понятно, почему Sleep (200) присутствует в шаблоне эксплойтов. Мы подозреваем, что это сделано для того, чтобы избежать ненужной нестабильности, особенно потому, что большинство этих эксплойтов основаны на времени (UAF, гонках).
Поэтому кратковременное ожидание завершения операций, связанных с вводом-выводом и доступом к памяти, может улучшить стабильность. Поскольку эксплойты являются частью вредоносного ПО, весь этот связанный с вредоносным ПО код перед
запуском эксплойта вызовет кратковременный всплеск загрузки ЦП / диска / ОЗУ, и, возможно, имеет смысл немного успокоиться, прежде чем переходить к самому эксплойту. Для кратковременной пиковой нагрузки (которая, естественно,
возникает при запуске новых процессов, чтении / записи файлов с диска и т. Д.) Должно хватить ожидания 200 мс.
Хотя мы заметили изменение этого шаблона в самых последних примерах, эту функцию все еще можно найти в 9 из обнаруженных нами эксплойтов.
К примеру: PlayBit не имеет такой особенности в своих эксплойтах.
Детектирование OS
Сразу после пробуждения от прекрасного сна эксплойт идентифицирует и калибрует себя под версию Windows цели, чтобы облегчить поддержку как можно большего количества версий ОС.
Судя по нашим образцам, автор запрашивает ОС двумя способами:
Парсинг заголовков ntdll.dll
Это наиболее часто используемый метод. Дескриптор в
GetVersionEx()
Этот метод обычно используется вместе с предыдущим и только в примерах с 2016 по начало 2017 года. Вероятно, это связано с тем, что этот API теперь устарел.
В обоих этих методах цель состоит в том, чтобы запросить как основную, так и вспомогательную версию ОС и соответствующим образом настроить глобальные переменные эксплойта.
Хотя большинство эксплойтов поддерживают широкий спектр версий Windows, Володя, похоже, никогда не заботится ни о конкретном пакете обновления целевого объекта, ни о том, является он сервером Windows или нет.
Помимо интереса к конкретным версиям сборки Windows 10, используемым только в эксплойте для CVE-2019-1458, наш субъект использует только основные и второстепенные версии, не более того.
В сравнении с PlayBit: Опять же используется
не только вместо
Это явная разница в образе действий обоих участников. Мало того, что они по-разному извлекают одну и ту же информацию, Володя интересуется гораздо меньшим объемом информации, чем PlayBit,
даже когда они оба используют одну и ту же уязвимость (CVE-2016-7255).
Как правило, оба субъекта содержат подробные конфигурации для конкретных версий, из которых они загружают соответствующую информацию после определения версии ОС. Основное различие между ними заключается в том,
что поток кода в эксплойтах Володи редко зависит от версии ОС, в то время как PlayBit включает в себя несколько поворотов и ручек, использующих различные проверки if, которые зависят от версии ОС. Это, в свою очередь,
влияет на их различный интерес к точным деталям версии.
Утечка адресов ядра
В подавляющем большинстве эксплойтов субъект настраивает эксплойт с помощью примитива утечки указателя ядра. Во всех эксплойтах, кроме CVE-2019-1458, этот примитив утечки является хорошо известным методом
во всех версиях Windows до Windows 10 RS4. Этот метод был хорошо известен и использовался еще в 2011 году, когда большинство руководств по эксплуатации специально анализировали
Удивительно видеть, что из десятков различных функций, которые можно использовать для поиска
Утечка дает нам следующее:
Обмен токенами
Конечная цель эксплойта - предоставить системные привилегии нужному процессу в соответствии с заданным аргументом PID. Традиционно для этого нужно заменить токен процесса в структуре
Вот несколько распространенных методов для этого. Вы будете удивлены, увидев, сколько существует различных вариантов реализации этой функции.
Использование символов Ps*
Ядро Windows содержит следующие функции и глобальные переменные, связанной с процессами:
Для этого есть 2 распространенных решения:
Сканирование PsList
Распространенной альтернативой для поиска
Шаги, включенные в эту технику:
Этот метод требует смещения как для первичного токена, так и для
Основным преимуществом этого метода является то, что, хотя он все еще может выполняться как простой шелл-код в режиме ядра (как это сделано в эксплойте
Для этого вам понадобятся два примитива эксплойтов: один для произвольного чтения (из пространства ядра), а другой для произвольной записи (в пространство ядра). Запуск в пользовательском режиме решает проблемы, которые мы подробно описывали ранее в отношении SMEP, делая эту защиту бесполезной против таких примитивов эксплойтов.
Поскольку токен является объектом с подсчетом ссылок, важно правильно зарегистрировать ссылку, которая только что была добавлена, чтобы избежать синего экрана смерти (BSOD) при завершении процесса с повышенными правами.
Фактически, существует два разных счетчика ссылок:
Маска выравнивания при чтении значения счетчика ссылок представляет собой выравнивание по 8 байтам, в то время при обратной записи используется другая маска. Если токен будет сохранен в адресе памяти,
который выровнен по 8 байтам и не выровнен по 16 байтам, операция записи обновит неправильное поле.
В то время как CVE-2016-0040 и CVE-2016-0167 используют технику Ps *, сканирование PsList, безусловно, является излюбленным способом обмена токенов для наших субъектов, они используют их в 8 эксплойтах.
В 7 из них они использовали произвольное чтение и произвольную запись из пользовательского режима.
В сравнении с PlayBit: Во всех их сэмплах мы всегда видели, как PlayBit использует функции
эксплойты для
конфигурации для смещения токена в
Стоит отметить, что метод повреждения памяти, который используется PlayBit в различных эксплойтах, также использовался Duqu 2.0 и был проанализирован в предыдущем выступлении Microsoft на VB от 2015 года.
Из-за этого повреждения памяти они могут вызвать несколько операций чтения/записи памяти из/в память ядра, которая поможет во время эксплойта.
Подведение итогов
Хотя есть дополнительные аспекты, которые мы могли бы обсудить, такие как различные системные вызовы, которые каждый субъект предпочитает использовать в процессе эксплуатации, соглашения об именах для созданных объектов,
таких как Windows и ScrollBars, мы считаем, что приведенный выше список ясно демонстрирует эффективность / валидность нашего подхода. Как видно из приведенного выше списка, почти каждый аспект эксплойта может быть реализован несколькими
способами. Тем не менее, оба наших cсубъекта были очень последовательны в своих действиях по эксплуатации, каждый придерживался своего любимого пути.
Заказчики
На протяжении всего нашего исследовательского процесса мы хотели сосредоточиться на самих авторах эксплойтов, будь то Володя, PlayBit или другие. И все же мы думаем, что есть чему поучиться, глядя на клиентуру этих авторов эксплойтов.
Список клиентов Володи разнообразен и включает авторов банковских троянцев, таких как Ursnif, авторов программ-вымогателей, таких как GandCrab, Cerber и Magniber, и APT-групп, таких как Turla, APT28 и Buhtrap (которые начинали с киберпреступности,
а затем перешли в кибершпионаж. ). Интересно, что мы видим, что 0-day Володи с большей вероятностью будут проданы APT-группам, в то время как 1-day будут приобретены несколькими группами криминального ПО.
Без дополнительной информации мы можем только предположить, что как только отрасль безопасности обнаружит 0-day, эксплойт будет переработан и продан по более низкой цене как 1-day.
Все клиенты APT, Turla, APT28 и Buhtrap, обычно относятся к России, и интересно обнаружить, что даже эти продвинутые группы покупают эксплойты, а не разрабатывают их собственными силами. Это еще один момент,
который еще больше усиливает нашу гипотезу о том, что написанные эксплойты можно рассматривать как отдельную и самостоятельную часть вредоносного ПО.
В следующей таблице приведены CVE, которые мы смогли приписать Володе, а также клиенты или группы вредоносных программ, обнаруженные нами с помощью этих эксплойтов. CVE, отмеченные синим цветом, относятся к нулевым дням и,
естественно, дороже. Выделенные слева группы считаются APT.
Они так быстро растут
Прежде чем рассматривать различные тенденции, которые мы отметили при изучении образцов эксплойтов за определенный период времени, мы должны подчеркнуть, что у нас ограниченная видимость, поскольку мы не можем обсуждать 0-days,
которые еще не были обнаружены. Кроме того, мы можем попытаться датировать образцы только периодом до того, как они были пойманы, но печальная правда заключается в том, что мы обычно в значительной степени привязаны к дате,
когда эксплойт был впервые обнаружен в дикой природе. Более того, нам важно упомянуть, что с самого начала было ясно, что Володя уже был достаточно профессионален при разработке первого эксплойта, который мы смогли приписать им
В ходе анализа эксплойтов, а также анализа десятков собранных нами образцов вредоносных программ мы заметили интересный сдвиг. В то время как ранние эксплойты Володи продавались как исходный код для встраивания во вредоносное ПО,
более поздние эксплойты продавались как внешняя утилита, принимающая определенный API. Это изменение может свидетельствовать о том, что Володя принимает дополнительные меры предосторожности.
В период с 2015 по 2019 год мы также заметили значительные улучшения технических навыков Володи. По мере того, как он становилися лучше и опытнее, Володя начал использовать более эффективные примитивы произвольного чтения и записи,
и он даже исправил ошибку в этих примитивах между CVE-2015-2546 и CVE-2016-0165 *. Более того, код эксплойтов стал более модульным, поскольку большие функции были разделены на более мелкие подпрограммы. Кроме того, их метод поиска и доступа
к определенным смещениям в различных структурах также был улучшен, а в последних реализациях он стал более динамичным и безопасным, поскольку он лучше обрабатывал изменения в дополнительных версиях Windows
Это не только показывает кривую обучения и развития нашего субъекта, но также намекает на его навыки. Найти и надежно использовать уязвимости ядра Windows на самом деле не так просто. Мы можем видеть для сравнения,
что PlayBit была очень активна на этом рынке в период с 2015 по 2018 год, и их внимание было сосредоточено на продаже эксплойтов для 1-дневных уязвимостей, одной из которых был 0-день Володи (CVE-2016- 7255).
Заключение
Наша методология исследования заключалась в том, чтобы определить характеристики автора эксплойтов, а затем использовать эти свойства в качестве уникальной охотничьей подписи. Мы дважды использовали эту технику при отслеживании эскплойтов
Володи и PlayBit. Имея эти два успешных тестовых примера, мы считаем, что эту методологию исследования можно использовать для выявления других авторов эксплойтов. Мы рекомендуем другим исследователям опробовать предложенную нами методику и
использовать ее в качестве дополнительного инструмента в своем арсенале.
В ходе этого исследования мы сосредоточили внимание на эксплойтах, которые используются или встроены в различные семейства вредоносных программ, как в APT-атаках, так и в массовых вредоносных программах (особенно в программах-вымогателях).
Хотя они широко распространены, мы часто находили подробные отчеты о вредоносных программах, в которых не упоминалось, что данное вредоносное ПО также использует эксплойт для повышения своих привилегий.
Тот факт, что мы смогли многократно использовать нашу технику для отслеживания 16 эксплойтов Windows LPE, написанных и проданных двумя разными участниками, был очень удивительным. Учитывая, что 15 из них относятся к периоду 2015–2019 годов,
можно предположить, что они составляют значительную долю рынка эксплойтов, особенно для эксплойтов Windows LPE.
Наконец, невозможно определить общее количество уязвимостей нулевого дня ядра Windows, которые активно используются в дикой природе. Национальные субъекты с меньшей вероятностью будут пойманы, и поэтому сообщество информационной
безопасности не имеет четкой видимости их ящика с боеприпасами. Тем не менее, мы все еще можем получить представление, глядя на обнаруженные эксплойты, помня об этой предвзятости к выживанию. В прошлом году «Лаборатория Касперского»
сообщила об одном субъекте, который распространил фреймворк эксплойтов, который включает еще 3 0-day. Суммируя эти цифры, мы видим, что 8 из 15 0-day эксплойтов, более половины «рыночной доли», приписываются только двум участникам (!).
Это означает, что наша исследовательская техника потенциально может быть использована для отслеживания многих участников видимого рынка, если не всех из них.
От ТС
Напоминаю что это перевод, оргинал - вот тут
Как и обещал успел перевести до вторника. Спасибо @weaver за интересный матерал, побольше бы такого. Самому было очень интересно переводить.
Если в тексте есть ошибки, пишите, исправлю по мере возможности. Текст большой, мог что-нибудь упустить.
В статье Володя то он, то они. Это не ошибка перевода, в оргинале всё точно также, авторы то имеют Володю в виду как человека, то как группу.
Перевод:
Azrv3l cпециально для xss.pro
В последние месяцы наши группы по исследованию уязвимостей и вредоносного ПО объединили усилия, чтобы сосредоточить внимание на эксплойтах внутри вредоносного ПО и, в частности, на самих разработчиках эксплойтов.
Начав с одной рекации на вторжение, мы создали профиль одного из самых активных разработчиков эксплойтов для Windows, известного как «Volodya» или «BuggiCorp». К настоящему моменту нам удалось отследить более 10 (!)
Их LPE эксплойтов в ядре Windows, многие из которых на момент разработки были 0-day.
Предыстория
Наша история начинается, как и все хорошие истории, с случая реакции на вторжение. При анализе сложной атаки на одного из наших клиентов мы заметили очень маленький 64-разрядный исполняемый файл, который был запущен вредоносной программой.
Образец содержал необычные отладочные строки, указывающие на попытку эксплуатации уязвимости на машине жертвы. Что еще более важно, в образце был оставшийся путь PDB, который четко и ясно декларировал цель этого двоичного файла:
...\cve-2019-0859\x64\Release\CmdTest.pdb. Из-за отсутствия какого-либо онлайн-ресурса с этой реализацией CVE-2019-0859 мы поняли, что рассматриваем не общедоступный PoC, а, скорее, реальный инструмент эксплуатации.Это заинтриговало наc, и мы решили копнуть глубже.
Реверс-инжиниринг эксплойта был довольно простым. Бинарный файл был маленьким, и отладочные сообщения указывали нам путь. Он использовал уязвимость use after free (UAF) в CreateWindowEx, чтобы повысить привилегии родительского процесса.
Мы быстро кое-что заметили: казалось, что эксплойт и само вредоносное ПО были написаны разными людьми. Качество кода, отсутствие обфускации, PDB и временных меток - все это указывало на сделаный нами вывод.
Распостранение эксплойта
Мы склонны смотреть на людей, стоящих за конкретным семейством вредоносных программ, как на одно целое. Легче представить, что каждый компонент был написан одним человеком, командой или группой.
По правде говоря, создание продвинутого вредоносного ПО национальными государствами или преступниками требует участия разных групп людей с разными навыками. Организация кибершпионажа национального государства, вероятно,
будет иметь сотни или даже тысячи сотрудников в различных группах и отраслях. У каждого сотрудника в организации своя роль, отлаженная благодаря специальной технологической подготовке и многолетнему опыту.
В такой организации рабочая нагрузка по написанию общих компонентов распределяется между специализированными командами, при этом разные группы отвечают за разные составляющие атаки:
первоначальный доступ, сбор конфиденциальных данных, боковые перемещения и многое другое.
Организация, цель которой - встроить модуль эксплойта в свое вредоносное ПО, не может полагаться только на разработчиков вредоносного ПО. Обнаружение уязвимости и ее эксплуатация, скорее всего, будет выполняться определенными группами
или отдельными лицами, которые специализируются на конкретной роли. Разработчики вредоносных программ, со своей стороны, не заботятся о том, как это работает за кулисами, они просто хотят интегрировать этот модуль и покончить с этим.
Чтобы такое разделение труда работало, обе команды должны согласовать некий API, который будет мостом между различными компонентами. Этот интеграционный API не является уникальным для государственных субъектов,
но является обычным явлением на «свободном рынке» эксплойтов. Будь то подпольные форумы, брокеры, использующие эксплойты, или наступательные кибер-компании, все они предоставляют своим клиентам инструкции о том,
как интегрировать эксплойт в свои вредоносные программы.
По сути, эта точка интеграции является ключевым аспектом, на котором мы хотели бы сосредоточиться в нашем исследовании. Предполагая, что авторы эксплойтов работают независимо и распространяют свой код/двоичный модуль только авторам
вредоносных программ, мы решили сосредоточиться на них. Анализируя эксплойты, встроенные в образцы вредоносных программ, мы можем больше узнать об авторах эксплойтов, надеясь провести различие между ними, изучив их привычки
программированияи и другие следы, оставленные в качестве ключей к их личности, при распространении их продуктов среди их коллег, пишущих вредоносное ПО.
Определение разработчика эксплойта
Вместо того, чтобы сосредотачиваться на всей вредоносной программе и искать новые образцы семейства вредоносных программ или участников, мы хотели предложить другую перспективу и решили сосредоточиться на этих нескольких функциях,
написанных разработчиком эксплойта. Получение этого небольшого 64-битного двоичного файла из случая реагирования на вторжение казалось многообещающим началом.
Бинарный файл не делал ничего, кроме использования CVE-2019-0859, и не был основан на исходном коде или POC, которые были доступны в паблике. Он стал для нас отличным кандидатом на поиск следов, так как исполняемый файл был доработан из кода,
написанного кем-то ещё, кроме автора эксплойта. Более того, исполняемый файл был отделен от основного двоичного файла вредоносного ПО, что заставило нас поверить, что этот эксплойт не был разработан темиже разработчиками что и вредоносное ПО.
С этой надеждой мы решили найти больше эксплойтов, написанных тем же автором.
Мы начали с сбора простых артефактов из уже имеющегося двоичного файла: строк, внутреннего имени файла, временных меток и пути PDB. Сразу пришел первый результат - 32-битный исполняемый файл, который полностью соответствовал
64-битному образцу. В частности, как показали их временные метки и встроенный путь PDB, они были скомпилированы вместе, в одно и то же время и из одного исходного кода. Теперь, когда у нас были эти два образца, мы смогли опеределиться с тем,
что нам следует искать.
Чтобы идентифицировать автора этого эксплойта, мы cосредоточили наше внимание на следующем:
- Уникальные артефакты в двоичных файлах
- Жестко закодированные значения (криптографические константы, «мусорные» значения, например 0x11223344)
- Таблицы данных (обычно конфигурации для конкретных версий)
- Строки (имена объектов GDI: «MyWindow», «MyClass_56», «findme1»,…)
- Путь к PDB
- Фрагменты кода
- Уникальная реализация функций
- Обертки системных вызовов
- Inline ассемблер
- Собственные криптографические функции
- Техники и привычки
- Предпочтительный метод утечки (HMValidateHandle, gSharedInfo и т.д)
- Предпочтительная техника повышения (как выполняется замена токена)
- Техника heap-spraying (с помощью AcceleratorTables? Windows? Bitmaps?)
- Фреймворк
- Поток выполнения эксплойта
- Вариант №1: Основной поток эксплойтов без побочных ответвлений
- Вариант №2: Множественные повороты для разных версий ОС
- Структура кода и функции в нём
- Модульность: разделение на функции
- Структура: разделение на фазы очистки (инициализация, конфигурирование, spraying, обмен токенами,…)
- Глобальные переменные: какая информация хранится в глобальных переменных? (Версия ОС? Перечисление версии ОС? Просто определенное смещение поля?)
- Конфигурации для конкретных версий:
- Смещения полей: Какие поля представляют особый интерес?
- Предпочтительные системные вызовы: предпочтительный набор системных вызовов
- API предоставленый заказчику
- Поток выполнения эксплойта
- Уникальная реализация функций
Помня об этих свойствах, мы оглянулись на два имеющихся у нас образца и отметили некоторые артефакты, которые мы считали уникальными. Несмотря на то, что у нас было только два небольших двоичных файла (которые по сути были одинаковыми),
мы смогли создать правила поиска, чтобы найти больше образцов, написанных этим разработчиком. К нашему удивлению, нам удалось найти их больше, чем мы ожидали.
Один за другим начали появляться десятки образцов, и с каждым из них мы улучшали наши правила и методики охоты. Тщательно проанализировав образцы, мы смогли понять, какие образцы эксплуатировали какие CVE,
и на основе этого создали временную шкалу, чтобы понять, был ли эксплойт 0-day или 1-day. это было реализовано на основе patch-diffing и аналогичных методов.
На данный момент у нас было более 10 CVE, которые мы могли отнести к одному разработчику эксплойтов, основываясь только на нашей методике снятия следов и без дополнительных аналитических данных.
Позже из публичных сообщений стало известно имя нашего целевого продавца эксплойтов: Володя (он же Володимир), ранее известный как BuggiCorp. Похоже, что мы были не единственными, кто отслеживал этого продавца эксплойтов,
поскольку Касперский несколько раз сообщал о них некоторую соответствующую информацию. Кроме того, ESET упомянул некоторые инкриминирующие следы Володи в своем выступлении на VB2019 о Buhtrap.
По словам Касперского, Володя впервые попал в заголовки под их ником BuggiCorp, когда они объявили о продаже Windows 0-day на известном форуме Exploit[.]in, со стартовой ценой 95 000 долларов. С годами цена росла, и некоторые из их 0-day
эксплойтов для Windows LPE продавались по цене до 200 000 долларов. Как было опубликовано в отчете Касперского и позже подтверждено нами, Володя продавал эксплойты как преступному ПО, так и группам APT.
Подробнее о его клиентах мы поговорим в разделе «Заказчики».
Эксплойты нашего подопечного
Хотя некоторые из наших первоначальных правил охоты нуждались в некоторой корректировке, даже немедленные результаты, которые мы получили, были довольно неожиданными. После дополнительной калибровки нам удалось найти множество примеров,
все из которых были эксплойтами Local Privilege Escalation (LPE) в Windows. Из этих образцов мы смогли идентифицировать следующий список CVE, которые использовались нашим субъектом.
Примечание:
При классификации эксплойтов мы выбрали консервативный подход при принятии решения о том, использовалась ли данная уязвимость как 0-Day или 1-Day. Если другие поставщики средств безопасности приписали эксплойт в условиях дикой
природы нашему подопечному, то это был 0-day. Если мы нашли достаточно доказательств того, что один из наших образцов действительно является распространяющимся в дикой природе эксплойтом, как это было описано поставщиком в их отчете,
мы также отметили его как таковой.
Во всех остальных случаях мы помечали уязвимость как 1-day, предпочитая иметь нижнюю границу отсчета 0-day вместо того, чтобы ошибочно превышать значения.
СVE-2015-2546
Тип: 1-day
Описание: Use-After-Free в
xxxSendMessage (tagPOPUPMENU)0-day репорт: FireEye
Был найден в следующих вредоносных ПО: Ursnif, Buhtrap
В наших сэмплах эксплойтов используется техника формирования памяти, отличная от описанной в первоначальном отчете: spraying Windows вместо Accelerator Tables. Кроме того,наш самый ранний и самый базовый пример эксплойта содержит
следующий путь PDB, предполагающий, что автору уже известен CVE-ID для этой уязвимости: «C:\…\volodimir_8\c2\CVE-2015-2546_VS2012\x64\Release\CmdTest. .pdb»
СVE-2016-0040
Тип: 1-day
Описание: Неинициализированный указатель ядра в
WMIDataDevice IOControl0-day репорт: N/A. Не был использован как 0-day
Был найден в следующих вредоносных ПО: Ursnif
Этот эксплойт использовался в единственном образце, который также содержал ранее описанный эксплойт для CVE-2015-2546. Этот эксплойт выбран, если целью является версия Windows более ранняя, чем Windows 8.
В противном случае используется CVE-2015-2546.
СVE-2016-0167
Тип: 0-day
Описание: Use-After-Free в
Win32k!xxxMNDestroyHandler0-day репорт: FireEye.
Был найден в следующих вредоносных ПО: PUNCHBUGGY
Наши образцы эксплойтов идеально согласуются с техническим отчетом об эксплойте в дикой природе.
СVE-2016-0165*
Тип: 1-day
Описание: Use-After-Free в
Win32k!xxxMNDestroyHandler0-day репорт: Обнаружена Kaspersky
Был найден в следующих вредоносных ПО: Ursnif
Это интересный случай. 0-Day нашего подопечного (CVE-2016-0167) был исправлен Microsoft в апреле 2016 года. Этот же патч также исправил CVE-2016-0165, который также использовался в дикой природе. В поисках новой уязвимости,
которую можно было бы использовать, наш субъект, вероятно, исправил исправления Microsoft и обнаружил уязвимость, которую они считали исправленной 0-Day. Эта уязвимость происходит из исправленной функции,
использованной в их предыдущей уязвимости:
Win32k!XxxMNDestroyHandler.*Из их образцов эксплойтов для этой уязвимости у нас есть несколько указаний на то, что либо автор эксплойта, либо, по крайней мере, их клиенты были уверены, что им продали эксплойт для CVE-2016-0165. Печальная правда в том,
что после анализа эксплойта мы можем сказать, что эксплуатируемая уязвимость отличается.
Эта путаница, вероятно, связана с тем, что Microsoft выпускает одно исправление, которое устраняет несколько уязвимостей, и только они имеют полное соответствие между каждым исправлением кода и выпущенной для него CVE.
СVE-2016-7255
Тип: 0-day
Описание: Повреждение памяти в
NtUserSetWindowLongPtr0-day репорт: Отмечено Google, технический отчёт от TrendMicro
Был найден в следующих вредоносных ПО: Был исползован APT28[они же Fancy-Bear, Sednit], позже использован Ursnif, Dreambot, GandCrab, Cerber, Maze
Наши образцы эксплойтов идеально согласуются с техническим отчетом об эксплойте в дикой природе. Этот конкретный эксплойт позже широко использовался различными организациями-вымогателями. Кроме того, мы видели и другие эксплойты для этой конкретной уязвимости, которые были проданы как 1-Days другим участникам программ-вымогателей.
Примечание: У нас есть несколько косвенных доказательств того, что именно этот 0-day был упомянут BuggiCorp в знаменитой рекламе, размещенной на форуме Explot[.]in в мае 2016 года.
СVE-2017-0001
Тип: 1-day
Описание: Use-After-Free в
RemoveFontResourceExW0-day репорт: N/A. Не был использован как 0-day
Был найден в следующих вредоносных ПО: Был использован Trula, позже Ursnif
Используется как 1-day в операциях, приписываемых Turla (FireEye).
СVE-2017-0263
Тип: 0-Day
Описание: Use-After-Free в
win32k!xxxDestroyWindow 0-day репорт: ESET
Был найден в следующих вредоносных ПО: Был использован APT28[они же Fancy-Bear, Sednit]
Наши образцы эксплойтов идеально согласуются с техническим отчетом об эксплойте в дикой природе.
СVE-2018-8641*
Тип: 1-Day
Описание: Двойное Освобождение Памяти в
win32k!xxxTrackPopupMenuEx0-day репорт: N/A. Не был использован как 0-day
Был найден в следующих вредоносных ПО: Magniber
Опять же, определение использованных 1-day обычно сложнее, чем определение 0-day. На этот раз мы не смогли найти ни одного примера, который мог бы намекнуть на уязвимость, которую, по мнению актера, он использовал.
*Мы определили, что эта конкретная уязвимость была исправлена Microsoft в декабре 2018 года. После сканирования списка уязвимостей, которые были устранены в этом исправлении, мы почти уверены,
что Microsoft пометила эту уязвимость как CVE-2018-8641, но мы не можем знать быть уверенны.
Обновление: 24 июня 2020 года Касперский опубликовал в своем блоге анализ эксплойтов, распространяемых с помощью эксплойт-кита Magnitude. В своем сообщении в блоге Касперский проанализировал эксплойт LPE,
использованный Magniber, приписал его Володе и оценил, что это, вероятно, CVE-2018-8641. Этот независимый вывод от имени Касперского подтверждает нашу первоначальную оценку.
СVE-2019-0859
Тип: 0-day
Описание: Use-After-Free в
CreateWindowEx0-day репорт: Kaspersky
Был найден в следующих вредоносных ПО: Используется как отдельный компонент для внедрения или загрузки. Мы не могли связать это с каким-либо конкретным APT / вредоносным ПО.
Наши образцы эксплойтов идеально согласуются с техническим отчетом об эксплойте в дикой природе. Наше исследование началось с одного образца эксплойта, который был обнаружен в сети клиента. В одном из примеров, которые мы нашли позже,
мы могли видеть эту чистую строку PDB:
X:\tools\0day\09-08-2018\x64\Releas \RunPS.pdb, в отличие от строки PDB в нашем начальном пример: S:\Work\Inject\cve-2019-0859\Release\CmdTest.pdb.СVE-2019-1132*
Тип: 0-day
Описание: NULL указатель в
win32k!xxxMNOpenHierarchy (tagPOPUPMENU)0-day репорт: ESET
Был найден в следующих вредоносных ПО: Был использован Buhtrap
* У нас есть несколько причин полагать, что это был еще один эксплойт 0-Day от Володи, поскольку многие технические детали в отчете соответствуют их типичным способам эксплуатации. Кроме того, эксплойт сообщил, что в него встроен следующий
путь PDB:
C:\work\volodimir_65\…pdb. Однако это единственный эксплойт в нашем списке, образец которого мы еще не нашли, и поэтому мы не можем быть уверены в нашей атрибуции этого эксплойта.СVE-2019-1458
Тип: 1-day
Описание: Повреждение памяти при переключении окон
0-day репорт: Kaspersky (Простой Отчёт, Более Детальный)
Был найден в следующих вредоносных ПО: Был использован WizardOpium
Наш эксплойт не соответствует техническому отчету об эксплойте в дикой природе. Кроме того, в своем подробном отчете «Лаборатория Касперского» отметила, что «также интересно, что мы обнаружили еще один однодневный эксплойт
для этой уязвимости всего через неделю после патча, что указывает на простоту использования этой уязвимости». И действительно, наша выборка датирована 6 днями после первоначального отчета Касперского.
Итоги по уязвимостям
Вот таблица, в которой перечислены перечисленные уязвимости:
Следы автора
Теперь, когда мы обнаружили более 10 различных эксплойтов Володи, мы можем рассмотреть их более подробно и ознакомиться с его привычками. С самого начала нам было ясно, что у нашего подопечного, вероятно, есть простой шаблон,
который они развертывают для различных эксплойтов, так как поток функций каждого эксплойта и даже порядок различных функций идентичен в большинстве эксплойтов.
В этом разделе мы описываем набор ключевых характеристик, которые отражают различные варианты реализации, выбранные Володей при создании шаблона эксплойта. Мы сравниваем их реализацию с реализацией другого автора эксплойтов,
известного под ником PlayBit. Путем этого сравнения мы стремимся очертить широкий спектр вариантов реализации, которые присутствуют в каждой части эксплойта,
делая набор вариантов реализации каждым автором уникальной «подписью» их образа мышления и работы.
PlayBit (a.k.a luxor2008)
Используя ту же технику, которую мы использовали для поиска эксплойтов Володи, нам удалось отследить 5 эксплойтов Windows LPE 1-Day, написанных PlayBit, в дополнение к другим инструментам, которые автор продавал на протяжении многих лет.
Мы начали с одного образца CVE-2018-8453, который используется программой-вымогателем REvil, и использовали уникальные отпечатки пальцев PlayBits для поиска новых эксплойтов.
Мы обнаружили следующие 1-day LPE эксплойты для Windows, реализованные этим автором:
- CVE-2013-3660
- CVE-2015-0057
- CVE-2015-1701
- CVE-2016-7255 – Это Володин 0-day
- CVE-2018-8453
а скорее являются уязвимостями в разных сервисах и, как таковые, имеют разную структуру.
Примечание: Более глубокий анализ PlayBit и различных эксплойтов, которые они разработали и продали, будет опубликован в следующем сообщении в блоге.
bool elevate(int target_pid)
API во всех примерах эксплойтов Володи всегда один и тот же. Независимо от того, был ли он встроен в образец вредоносного ПО или был отдельным POC,
эксплойт имел единственную функцию API со следующей сигнатурой:
C:
bool elevate(int target_pid)Сам эксплойт не включает никаких функций для внедрения шелл-кода в другой процесс или чего-либо подобного.
Он предоставляет системные привилегии желаемому процессу, не принимая в качестве аргумента ничего, кроме его PID.
Sleep(200)
Самое первое, что делает функция
elevate() сразу после ее вызова вредоносной программой, - это Sleep() на постоянный период времени в 200 миллисекунд.
Не совсем понятно, почему Sleep (200) присутствует в шаблоне эксплойтов. Мы подозреваем, что это сделано для того, чтобы избежать ненужной нестабильности, особенно потому, что большинство этих эксплойтов основаны на времени (UAF, гонках).
Поэтому кратковременное ожидание завершения операций, связанных с вводом-выводом и доступом к памяти, может улучшить стабильность. Поскольку эксплойты являются частью вредоносного ПО, весь этот связанный с вредоносным ПО код перед
запуском эксплойта вызовет кратковременный всплеск загрузки ЦП / диска / ОЗУ, и, возможно, имеет смысл немного успокоиться, прежде чем переходить к самому эксплойту. Для кратковременной пиковой нагрузки (которая, естественно,
возникает при запуске новых процессов, чтении / записи файлов с диска и т. Д.) Должно хватить ожидания 200 мс.
Хотя мы заметили изменение этого шаблона в самых последних примерах, эту функцию все еще можно найти в 9 из обнаруженных нами эксплойтов.
К примеру: PlayBit не имеет такой особенности в своих эксплойтах.
Детектирование OS
Сразу после пробуждения от прекрасного сна эксплойт идентифицирует и калибрует себя под версию Windows цели, чтобы облегчить поддержку как можно большего количества версий ОС.
Судя по нашим образцам, автор запрашивает ОС двумя способами:
Парсинг заголовков ntdll.dll
Это наиболее часто используемый метод. Дескриптор в
ntdll.dll используется для поиска смещения в IMAGE_NT_HEADERS, из которого анализируются поля MajorOperatingSystemVersion и MinorOperatingSystemVersion.GetVersionEx()
Этот метод обычно используется вместе с предыдущим и только в примерах с 2016 по начало 2017 года. Вероятно, это связано с тем, что этот API теперь устарел.
В обоих этих методах цель состоит в том, чтобы запросить как основную, так и вспомогательную версию ОС и соответствующим образом настроить глобальные переменные эксплойта.
Хотя большинство эксплойтов поддерживают широкий спектр версий Windows, Володя, похоже, никогда не заботится ни о конкретном пакете обновления целевого объекта, ни о том, является он сервером Windows или нет.
Помимо интереса к конкретным версиям сборки Windows 10, используемым только в эксплойте для CVE-2019-1458, наш субъект использует только основные и второстепенные версии, не более того.
В сравнении с PlayBit: Опять же используется
GetVersionEx(), обычно с последующим дополнительным анализом основных и второстепенных номеров из самого блока среды процесса (PEB), как показано на рисунке 7. PEB используетсяне только вместо
ntdll.dll, PlayBit также извлекает дополнительную информацию из вывода GetVersionEx(), такую как пакет обновления компьютера, и даже проверяет, использует ли целевой компьютер серверную операционную систему.
Это явная разница в образе действий обоих участников. Мало того, что они по-разному извлекают одну и ту же информацию, Володя интересуется гораздо меньшим объемом информации, чем PlayBit,
даже когда они оба используют одну и ту же уязвимость (CVE-2016-7255).
Как правило, оба субъекта содержат подробные конфигурации для конкретных версий, из которых они загружают соответствующую информацию после определения версии ОС. Основное различие между ними заключается в том,
что поток кода в эксплойтах Володи редко зависит от версии ОС, в то время как PlayBit включает в себя несколько поворотов и ручек, использующих различные проверки if, которые зависят от версии ОС. Это, в свою очередь,
влияет на их различный интерес к точным деталям версии.
Утечка адресов ядра
В подавляющем большинстве эксплойтов субъект настраивает эксплойт с помощью примитива утечки указателя ядра. Во всех эксплойтах, кроме CVE-2019-1458, этот примитив утечки является хорошо известным методом
HMValidateHandle.HMValidateHandle() - это внутренняя неэкспортированная функция из user32.dll, которая используется различными функциями, такими как isMenu (), и может использоваться для получения адресов ядра различных объектов Windowво всех версиях Windows до Windows 10 RS4. Этот метод был хорошо известен и использовался еще в 2011 году, когда большинство руководств по эксплуатации специально анализировали
isMenu(), чтобы найти адрес HMValidateHandle().Удивительно видеть, что из десятков различных функций, которые можно использовать для поиска
HMValidateHandle(), cубъект просто следовал хорошо известным руководствам и также решил использовать isMenu(). Еще более удивительно видеть, что эта распространенная техника эксплуатации все еще работала достаточно хорошо на протяжении многих лет, не давая субъекту стимула пытаться «спрятаться», выбирая менее известную функцию, такую как CheckMenuRadioItem().Утечка дает нам следующее:
- kernel адрес нашего окна
- kernel адрес нашего THREAD_INFO (поле pti).
- Адреса используются при указании/создании поддельных структур ядра.
- Убедиться в том, что адрес нашего ядра является допустимой строкой Unicode (не содержит нулевых байтов «\x00»).
- Pti используется для поиска действительного EPROCESS, который затем используется на этапе обмена токенами.
Обмен токенами
Конечная цель эксплойта - предоставить системные привилегии нужному процессу в соответствии с заданным аргументом PID. Традиционно для этого нужно заменить токен процесса в структуре
EPROCESS/KPROCESS на токен процесса SYSTEM.Вот несколько распространенных методов для этого. Вы будете удивлены, увидев, сколько существует различных вариантов реализации этой функции.
Использование символов Ps*
Ядро Windows содержит следующие функции и глобальные переменные, связанной с процессами:
- PsLookupProcessByProcessId - извлекает указатель на EPROCESS процесса.
- PsInitialSystemProcess - глобальная переменная, содержащая указатель на EPROCESS системы.
- PsReferencePrimaryToken - возвращает указатель на первичный токен процесса.
EPROCESS.Для этого есть 2 распространенных решения:
- Прямой доступ к правильному смещению внутри
EPROCESS, используя смещение, зависящее от версии. - Просканирование
EPROCESSв поисках нашего собственного указателя (известного по предыдущему вызову PsReferencePrimaryToken) и замена записи, как только будет найдено совпадение.
Сканирование PsList
Распространенной альтернативой для поиска
EPROCESS как целевого, так и системного процессов является сканирование двусвязного списка процессов, называемого PsList. Шаги, включенные в эту технику:
- Найти начальный ЭПРОЦЕСС (используя утекшее поле pti).
- Просканировать PsList в поисках
EPROCESSс целевым PID. - Просканировать PsList в поисках
SYSTEM EPROCESS, ища PID, равный 4, или имяSYS *. - Извлеч токен и поместить его в соответствующее смещение в целевом процессе.
- Обновить счетчик ссылок токена SYSTEM.
Этот метод требует смещения как для первичного токена, так и для
LIST_ENTRY для PsList, в значительной степени требуя, чтобы они оба хранились как часть конфигурации для конкретной версии.Основным преимуществом этого метода является то, что, хотя он все еще может выполняться как простой шелл-код в режиме ядра (как это сделано в эксплойте
CVE-2017-0263), он также может быть полностью реализован в пользовательском режиме. Для этого вам понадобятся два примитива эксплойтов: один для произвольного чтения (из пространства ядра), а другой для произвольной записи (в пространство ядра). Запуск в пользовательском режиме решает проблемы, которые мы подробно описывали ранее в отношении SMEP, делая эту защиту бесполезной против таких примитивов эксплойтов.
Поскольку токен является объектом с подсчетом ссылок, важно правильно зарегистрировать ссылку, которая только что была добавлена, чтобы избежать синего экрана смерти (BSOD) при завершении процесса с повышенными правами.
Фактически, существует два разных счетчика ссылок:
- EX_FAST_REF - младшие биты указателя используются как счётчик ссылок
- OBJECT_HEADER хранится до токена, и содежит ещё один счётчик ссылок
- Маскируем биты счетчика ссылок из указателя токена - должны быть выровнены по 8 байтам в 32-битных процессах и 16 байтам в 64-битных процессах.
- Вычитаем константу, необходимую для указания на поле счетчика ссылок OBJECT_HEADER.
- Читаем значение (используя примитив эксплойта произвольного чтения).
- Инкрементируем
- Записываем обновлённое значние
Маска выравнивания при чтении значения счетчика ссылок представляет собой выравнивание по 8 байтам, в то время при обратной записи используется другая маска. Если токен будет сохранен в адресе памяти,
который выровнен по 8 байтам и не выровнен по 16 байтам, операция записи обновит неправильное поле.
В то время как CVE-2016-0040 и CVE-2016-0167 используют технику Ps *, сканирование PsList, безусловно, является излюбленным способом обмена токенов для наших субъектов, они используют их в 8 эксплойтах.
В 7 из них они использовали произвольное чтение и произвольную запись из пользовательского режима.
В сравнении с PlayBit: Во всех их сэмплах мы всегда видели, как PlayBit использует функции
Ps* для обмена токенами. Это решение вынудило субъект реализовать несколько обходов SMEP, которые они интегрировали в свои более поздние эксплойты для
CVE-2016-7255 и CVE-2018-8453. Этот выбор дизайна объясняет, почему субъект заботится о реализации правильного примитива произвольного чтения как части эксплойта. Вместо использования зависящей от версии конфигурации для смещения токена в
EPROCESS, PlayBit всегда сканирует EPROCESS для его поиска, обычно используя 0x300 или 0x600 в качестве верхнего предела для поиска. Стоит отметить, что метод повреждения памяти, который используется PlayBit в различных эксплойтах, также использовался Duqu 2.0 и был проанализирован в предыдущем выступлении Microsoft на VB от 2015 года.
Из-за этого повреждения памяти они могут вызвать несколько операций чтения/записи памяти из/в память ядра, которая поможет во время эксплойта.
Подведение итогов
Хотя есть дополнительные аспекты, которые мы могли бы обсудить, такие как различные системные вызовы, которые каждый субъект предпочитает использовать в процессе эксплуатации, соглашения об именах для созданных объектов,
таких как Windows и ScrollBars, мы считаем, что приведенный выше список ясно демонстрирует эффективность / валидность нашего подхода. Как видно из приведенного выше списка, почти каждый аспект эксплойта может быть реализован несколькими
способами. Тем не менее, оба наших cсубъекта были очень последовательны в своих действиях по эксплуатации, каждый придерживался своего любимого пути.
Заказчики
На протяжении всего нашего исследовательского процесса мы хотели сосредоточиться на самих авторах эксплойтов, будь то Володя, PlayBit или другие. И все же мы думаем, что есть чему поучиться, глядя на клиентуру этих авторов эксплойтов.
Список клиентов Володи разнообразен и включает авторов банковских троянцев, таких как Ursnif, авторов программ-вымогателей, таких как GandCrab, Cerber и Magniber, и APT-групп, таких как Turla, APT28 и Buhtrap (которые начинали с киберпреступности,
а затем перешли в кибершпионаж. ). Интересно, что мы видим, что 0-day Володи с большей вероятностью будут проданы APT-группам, в то время как 1-day будут приобретены несколькими группами криминального ПО.
Без дополнительной информации мы можем только предположить, что как только отрасль безопасности обнаружит 0-day, эксплойт будет переработан и продан по более низкой цене как 1-day.
Все клиенты APT, Turla, APT28 и Buhtrap, обычно относятся к России, и интересно обнаружить, что даже эти продвинутые группы покупают эксплойты, а не разрабатывают их собственными силами. Это еще один момент,
который еще больше усиливает нашу гипотезу о том, что написанные эксплойты можно рассматривать как отдельную и самостоятельную часть вредоносного ПО.
В следующей таблице приведены CVE, которые мы смогли приписать Володе, а также клиенты или группы вредоносных программ, обнаруженные нами с помощью этих эксплойтов. CVE, отмеченные синим цветом, относятся к нулевым дням и,
естественно, дороже. Выделенные слева группы считаются APT.
Они так быстро растут
Прежде чем рассматривать различные тенденции, которые мы отметили при изучении образцов эксплойтов за определенный период времени, мы должны подчеркнуть, что у нас ограниченная видимость, поскольку мы не можем обсуждать 0-days,
которые еще не были обнаружены. Кроме того, мы можем попытаться датировать образцы только периодом до того, как они были пойманы, но печальная правда заключается в том, что мы обычно в значительной степени привязаны к дате,
когда эксплойт был впервые обнаружен в дикой природе. Более того, нам важно упомянуть, что с самого начала было ясно, что Володя уже был достаточно профессионален при разработке первого эксплойта, который мы смогли приписать им
CVE-2015-2546. Например, у него был уникальный примитив произвольной записи, который мы не могли отследить ни в одном другом учебнике по эксплуатации/эксплойте.В ходе анализа эксплойтов, а также анализа десятков собранных нами образцов вредоносных программ мы заметили интересный сдвиг. В то время как ранние эксплойты Володи продавались как исходный код для встраивания во вредоносное ПО,
более поздние эксплойты продавались как внешняя утилита, принимающая определенный API. Это изменение может свидетельствовать о том, что Володя принимает дополнительные меры предосторожности.
В период с 2015 по 2019 год мы также заметили значительные улучшения технических навыков Володи. По мере того, как он становилися лучше и опытнее, Володя начал использовать более эффективные примитивы произвольного чтения и записи,
и он даже исправил ошибку в этих примитивах между CVE-2015-2546 и CVE-2016-0165 *. Более того, код эксплойтов стал более модульным, поскольку большие функции были разделены на более мелкие подпрограммы. Кроме того, их метод поиска и доступа
к определенным смещениям в различных структурах также был улучшен, а в последних реализациях он стал более динамичным и безопасным, поскольку он лучше обрабатывал изменения в дополнительных версиях Windows
Это не только показывает кривую обучения и развития нашего субъекта, но также намекает на его навыки. Найти и надежно использовать уязвимости ядра Windows на самом деле не так просто. Мы можем видеть для сравнения,
что PlayBit была очень активна на этом рынке в период с 2015 по 2018 год, и их внимание было сосредоточено на продаже эксплойтов для 1-дневных уязвимостей, одной из которых был 0-день Володи (CVE-2016- 7255).
Заключение
Наша методология исследования заключалась в том, чтобы определить характеристики автора эксплойтов, а затем использовать эти свойства в качестве уникальной охотничьей подписи. Мы дважды использовали эту технику при отслеживании эскплойтов
Володи и PlayBit. Имея эти два успешных тестовых примера, мы считаем, что эту методологию исследования можно использовать для выявления других авторов эксплойтов. Мы рекомендуем другим исследователям опробовать предложенную нами методику и
использовать ее в качестве дополнительного инструмента в своем арсенале.
В ходе этого исследования мы сосредоточили внимание на эксплойтах, которые используются или встроены в различные семейства вредоносных программ, как в APT-атаках, так и в массовых вредоносных программах (особенно в программах-вымогателях).
Хотя они широко распространены, мы часто находили подробные отчеты о вредоносных программах, в которых не упоминалось, что данное вредоносное ПО также использует эксплойт для повышения своих привилегий.
Тот факт, что мы смогли многократно использовать нашу технику для отслеживания 16 эксплойтов Windows LPE, написанных и проданных двумя разными участниками, был очень удивительным. Учитывая, что 15 из них относятся к периоду 2015–2019 годов,
можно предположить, что они составляют значительную долю рынка эксплойтов, особенно для эксплойтов Windows LPE.
Наконец, невозможно определить общее количество уязвимостей нулевого дня ядра Windows, которые активно используются в дикой природе. Национальные субъекты с меньшей вероятностью будут пойманы, и поэтому сообщество информационной
безопасности не имеет четкой видимости их ящика с боеприпасами. Тем не менее, мы все еще можем получить представление, глядя на обнаруженные эксплойты, помня об этой предвзятости к выживанию. В прошлом году «Лаборатория Касперского»
сообщила об одном субъекте, который распространил фреймворк эксплойтов, который включает еще 3 0-day. Суммируя эти цифры, мы видим, что 8 из 15 0-day эксплойтов, более половины «рыночной доли», приписываются только двум участникам (!).
Это означает, что наша исследовательская техника потенциально может быть использована для отслеживания многих участников видимого рынка, если не всех из них.
От ТС
Напоминаю что это перевод, оргинал - вот тут
Как и обещал успел перевести до вторника. Спасибо @weaver за интересный матерал, побольше бы такого. Самому было очень интересно переводить.
Если в тексте есть ошибки, пишите, исправлю по мере возможности. Текст большой, мог что-нибудь упустить.
В статье Володя то он, то они. Это не ошибка перевода, в оргинале всё точно также, авторы то имеют Володю в виду как человека, то как группу.
Перевод:
Azrv3l cпециально для xss.pro
