Существует теория, согласно которой, если кому-либо удастся украсть и использовать кибернетические инструменты национального уровня, любая сеть станет ненадежной, и мир станет очень опасным местом для жизни.
Есть еще одна теория, которая утверждает, что это уже произошло.
Что бы вы сказали, если бы мы сказали вам, что иностранной группе удалось украсть американскую атомную подводную лодку? Это определенно будет плохо и быстро попадет в каждый заголовок газеты.
Однако с кибероружием - хотя его воздействие может быть столь же разрушительным - обычно все обстоит иначе.
Кибероружие является цифровым и нестабильным по своей природе. Чтобы украсть их и переправить с одного континента на другой, достаточно отправить электронное письмо. Они также очень неясны, и их существование является тщательно охраняемым секретом. Именно поэтому, в отличие от атомной подводной лодки, кража кибер-оружия может легко остаться незамеченной и стать фактом, известным лишь немногим избранным.
Последствия такого сценария могут быть разрушительными, поскольку мир уже испытал на себе случай утечки Shadow Brokers, когда таинственная группа решила публично опубликовать широкий спектр кибероружия, предположительно разработанного Tailored Access Operations (TAO) подразделение АНБ - также именуемое "Equation Group". Утечка Shadow Brokers привела к одним из крупнейших кибер-вспышек в истории, самой известной из которых была атака WannaCry, нанесшая сотни миллионов долларов убытков организациям по всему миру, и ее последствия по-прежнему актуальны даже через 3 года после её запуска.
Однако утечка Shadow brokers просто дала нам представление о некоторых возможных последствиях, которые может вызвать такая кибер-кража. Остается еще много важных вопросов - могло ли такое случиться раньше? И если да, то кто за этим стоит и для чего они его использовали?
Наше недавнее исследование направлено на то, чтобы пролить больше света на эту тему и выявить убедительные доказательства того, что такая утечка действительно имела место за годы до утечки Shadow Brokers, в результате чего разработанные в США кибер-инструменты попали в руки китайской группы, которая перепрофилировала их, чтобы атаковать цели США.
Ключевые находки
Введение
В последние несколько месяцев наши исследователи вредоносных программ и уязвимостей сосредоточили внимание на недавних эксплойтах для повышения привилегий Windows, приписываемых китайским хакерам. В ходе этого расследования нам удалось раскрыть скрытую историю "Jian", эксплойта нулевого дня, который ранее приписывался APT31 (Zirconium), и показать его истинное происхождение.
В этом блоге мы показываем, что CVE-2017-0005, уязвимость Windows Local-Privilege-Escalation (LPE), которая была приписана китайскому APT, была реплицирована на основе эксплойта Equation Group для той же уязвимости, к которой APT смог получить доступ. EpMe, эксплойт Equation Group для CVE-2017-0005, является одним из 4 различных эксплойтов LPE, включенных в структуру фреймворка DanderSpritz. EpMe восходит как минимум к 2013 году - за четыре года до того, как APT31 был пойман на использовании этой уязвимости в дикой природе.
Это не первый задокументированный случай, когда китайский APT перепрофилировал эксплойт Equation Group. В случае с Bemstour, который обсуждали как Symantec, так и наша собственная исследовательская группа, основное предположение заключалось в том, что APT3 (Buckeye) проснифал эксплойт EternalRomance из сетевого трафика, а затем обновил его до эквивалента EternalSynergy, используя дополнительную уязвимость APT3. Однако в данном случае у нас есть веские доказательства того, что APT31 имел доступ к фактическим файлам эксплойтов Equation Group как в 32-битной, так и в 64-битной версиях.
В следующих разделах мы представляем 4 различных эксплойта Windows LPE, включенных в фреймворк DanderSpritz, и раскрываем дополнительный код эксплойта под названием "EpMo". Этот эксплойт был пропатчен в мае 2017 года, вероятно, как часть последующих исправлений утечки Shadow Brokers "Lost in Translation" инструментов Equation Group. Хотя уязвимость была исправлена, нам не удалось идентифицировать связанный с ней CVE-ID. Насколько нам известно, это первое публичное упоминание о существовании этой дополнительной уязвимости Equation Group.
Background
В рамках нашего постоянного исследования эксплойтов Windows LPE и отслеживания авторов эксплойтов мы начали анализировать эксплойты, приписываемые китайским APT. Поскольку CVE-2019-0803 недавно был упомянут в списке 25 основных уязвимостей АНБ, используемых китайскими хакерами, мы решили, что это хорошее место для начала. После того, как мы закончили документирование всей информации, которую мы собрали об этом уникальном эксплойте, который первоначально был связан с китайскими хакерами, мы перешли к следующему эксплойту с китайской атрибутикой в нашем списке: CVE-2017-0005.
В нашем обзоре отчета Microsoft об уязвимости, которая была обнаружена в открытом доступе и приписывалась Zirconium (APT31), мы обнаружили несколько интересных деталей:
Вооруженные этими двумя зацепками и уже знакомые с упаковщиком, используемым этими эксплойтами, мы приступили к поиску описанного эксплойта CVE-2017-0005.
Получив 64-битный образец эксплойта CVE-2017-0005, мы проверили его на соответствие информации, описанной Microsoft в их блоге. Мало того, что это совпадало, при игнорировании случайного распределения страниц оба образца использовали одни и те же адреса (те же самые младшие 3 полубайта).
Сравнение CVE-2017-0005 и CVE-2019-0803
В следующем разделе мы подробно опишем некоторые характеристики упаковщика и загрузчика, используемых в CVE-2017-0005 и CVE-2019-0803, и подчеркнем их общие черты и различия.
Jian, эксплойт CVE-2017-0005, поставлялся в виде DLL с именем Add.dll. Он содержал интересный путь PDB, предполагающий, что он был написан в 2015 году в рамках проекта под названием "rundll32_getadmin".
F:\\code\\2015\\rundll32_getadmin\\Add\\x64\\Release\\Add.pdb
Когда мы проверили метку даты и времени двоичного файла в заголовке файла, мы увидели, что DLL была скомпилирована 6 мая, в среду, 02:08:24 2015 г., что хорошо согласуется с именем папки из PDB. Дополнительная отметка времени в каталоге экспорта указывает на ту же дату. Говоря о каталоге экспорта, DLL имеет единственную экспортируемую функцию с именем "AddByGod|, которая, как мы вскоре узнаем, является функцией входа для упаковщика.
Процедура дешифрования очень проста. Упаковщик начинает с выделения памяти для зашифрованного кода и копирует его во вновь выделенный буфер. Затем он выделяет буфер с защитой PAGE_EXECUTE_READWRITE для хранения расшифрованного кода. После распределения буферов упаковщик проверяет, был ли передан строковый аргумент, который будет использоваться в качестве ключа дешифрования, в функцию AddByGod. Затем упаковщик использует алгоритм AES256 с ключом, полученным из SHA1 переданного аргумента, для расшифровки зашифрованного кода. Если расшифровка прошла успешно, выполняется расшифрованный код и запускаются полезные данные второго этапа. К счастью, нам удалось получить пароль, необходимый для выполнения двоичного файла и дешифрования зашифрованных данных.
rundll32.exe Add.dll AddByGod [password]
Второй этап начинается с типичной техники шелл-кода, поиска в заголовке модуля адреса kernel32.dll и динамического получения указателя на функцию экспорта GetProcAddress. Затем программа распаковывает другой переносимый исполняемый файл (PE) и переходит к его точке входа. Распакованный PE, который является 3-м этапом в последовательности загрузки, имеет намеренно поврежденные заголовки. Он выполняет базовые операции загрузки, а затем начинается с рефлексивной загрузки встроенного исполняемого файла (да, еще одного). Загруженный PE является последним этапом в последовательности загрузки и отвечает за выполнение эксплойта.
Интересно отметить, что время компиляции встроенного двоичного файла - самого эксплойта - датируется октябрем 2014 года. Это говорит о том, что злоумышленники использовали этот зеро-дэй в 2014 году, почти за три года до того, как он стал общедоступным в утечке Shadow Brokers и был исправлен Microsoft.
Как видно на рисунке выше, упаковщик, используемый для CVE-2019-0803, очень похож на упаковщик, используемый в CVE-2017-0005. На самом деле поток практически идентичен. Файл был скомпилирован 18 сентября 2018 г. и также имеет внутреннее имя "Add.dll". Как и ранее упакованный эксплойт, CVE-2019-0803 также имеет функцию экспорта с именем "AddByGod" и содержит отладочную информацию:
C:\Users\sms2056\Desktop\Add（未修改dll‘）\x64\Release\Add.pdb
В отличие от предыдущего примера, в этом примере используется другой пароль для дешифрования, и при запуске требуется дополнительный аргумент (используется на более поздних этапах). Затем поток выполнения продолжается точно так же, как мы наблюдали в предыдущем примере, за одним исключением: после того, как программа распаковывает полезную нагрузку PE и переходит к своей точке входа, у нее нет 4-го этапа другого встроенного PE, а просто начинается этап эксплуатации.
Мы искали другие образцы, в которых используется этот или аналогичный вариант описанного нами упаковщика, и обнаружили несколько образцов и семейств вредоносных программ, которые использовали его в течение многих лет. Все вредоносные программы явно и исключительно приписываются китайским группам атак. Добавление этого вывода к имеющейся у нас контекстной информации, независимой атрибуции Microsoft CVE-2017-0005 китайской APT и атрибутикой NSA CVE-2019-0803 "китайским государственным спонсорам" заставляет нас полагать, что эксплойт CVE-2017-0005 действительно использовался злоумышленниками, входящими в состав китайской группировки.
Jian – CVE-2017-0005
Анализируя Jian, мы заметили следующие интересные особенности.
Контекст версия операционной системы
Эксплойт создает контекст расширенной версии, который включает в себя несколько полей, каждое из которых представляет различные характеристики целевой операционной системы. Этот обширный контекст не типичен для китайских эксплойтов, которые мы проанализировали ранее, и выглядит как своего рода утилита/фреймворк. Это еще более подозрительно, поскольку некоторые поля в контексте даже не инициализированы (отмечены красным), а в целом только три из них используются самим эксплойтом (отмечены синим).
Для сравнения: эксплойт CVE-2019-0803 поддерживал только одну версию Windows и использовал жестко запрограммированные зависящие от версии константы для Windows Server 2008 R2. Alibaba даже сообщила, что имя файла инструмента было 2008.dll, что не оставляло сомнений в его предназначении.
Таблица глобальной конфигурации
Перечисление версий ОС используется в качестве индекса для глобальной таблицы конфигурации. Это классический пример использования такого перечисления, когда требуется конфигурация, зависящая от версии. Сама таблица конфигурации выглядит как многообещающий артефакт, который может появиться в дополнительных эксплойтах тех же авторов.
Мы создали сигнатуры обнаружения и искали образцы, содержащие эту таблицу конфигурации. По нашему поисковому запросу были получены следующие образцы:
Соглашение об именах файлов и их контекст сразу же застали нас врасплох. Мы признали их частью утечки инструментов Equation Group, произведенной Shadow Brokers. Equation Group - это название, данное группе APT, которая считается подразделением Tailored Access Operations (TAO) Агентства национальной безопасности США. Как наш поиск чрезвычайно уникальных артефактов, извлеченных из китайского эксплойта нулевого дня, исправленного в марте 2017 года, показал результаты утечки инструментов Equation Group с 2013 года? Чтобы ответить на этот вопрос, мы начали углубляться и анализировать найденную информацию.
Lost In Translation
Прежде чем описывать наш анализ, мы хотим дать краткую историю группы The Shadow Brokers и их утечки инструментов Equation Group. Мы считаем, что понимание природы утечки, и особенно графика, имеет решающее значение для понимания того, что произошло дальше.
Shadow Brokers - это загадочная группа хакеров, впервые появившаяся 12 августа 2016 года, когда они пригласили общественность принять участие в аукционе "Кибероружия" Equation Group. С тех пор группа начала выпускать все больше и больше файлов в течение нескольких месяцев. Одна из этих утечек, получившая название Lost in Translation, появилась в апреле 2017 года и хорошо известна тем, что выпустила печально известные эксплойты Equation Group, такие как Eternal Blue.
Одним из основных компонентов этой утечки является DanderSpritz, фреймворк пост-эксплуатации Equation Group, который содержит широкий спектр инструментов для постоянства, разведки, бокового перемещения, обхода антивирусных механизмов и т.д. Структура очень модульная и предоставляет оператору множество возможностей для доступа к компьютерам жертв. В течение последних месяцев мы пересмотрели фреймворк DanderSpritz, реконструировали некоторые из его модулей и имплантатов и планируем опубликовать подробную публикацию, посвященную фреймворку и нашим открытиям.
Наш проект профилирования авторов эксплойтов фокусируется на эксплойтах Windows LPE, таких как CVE-2017-0005, артефакты которых мы искали. Как это часто бывает во фреймворках пост-эксплуатации, DanderSpritz и утечка Lost In Translation также содержат эксплойты LPE, и два из них соответствуют нашему запросу.
Теперь мы представляем краткий обзор некоторых эксплойтов LPE, которые были приписаны Equation Group, и их связи с просочившейся структурой DanderSpritz.
История эксплойтов Equation Group LPE
PrivLib и Houston Disk
Термин "PrivLib" часто используется для обозначения модуля повышения привилегий, встроенного в данный имплант Equation Group. PrivLib содержит выбранный набор эксплойтов Windows LPE, выбранных из арсенала Equation Group, и все они заключены в тонкую оболочку, известную своим уникальным мьютексом prkMtx.
В 2015 году Касперский сообщил о наборе Windows LPE, встроенных в booby-trapped диск, который был передан на научном съезде в Хьюстоне. Все эксплойты, приписываемые Equation Group, были зеродеями на момент разработки, а некоторые даже датировались 2008 годом. В общем, диск Houston Disk содержал версию PrivLib, которая запускает набор из 3 эксплойтов один за другим, пока не будут получены желаемые привилегии.
Вот список эксплойтов, содержащихся на диске, в соответствии с порядком их выполнения:
- MS09-025 (Fanny / Stuxnet)
- CVE-2013-3128
- CVE-2011-3402
Примечание. Перечисленные здесь CVE не совпадают с теми, которые изначально были упомянуты "Лабораторией Касперского" в своем отчете. Во-первых, исследователи Касперского с самого начала не были уверены в идентификаторах CVE-ID, отметив их как "возможно". Во-вторых, мы нашли дополнительную информацию о последних двух эксплойтах, которая помогла пролить свет на более вероятные идентификаторы CVE для каждого из них. Более подробную информацию об идентификации CVE-ID можно найти позже в соответствующих разделах, описывающих каждый эксплойт.
DanderSpritz NtElevation
DanderSpritz - это модульный фреймворк пост-эксплуатации, который содержит десятки различных взаимозависимых модулей. Например, некоторые модули не запускаются, если сначала не выполняются определенные модули, а для других требуются особые привилегии или артефакты. Для запуска некоторых модулей требуются привилегии учетной записи SYSTEM. Для этого DanderSpritz запускает набор модулей под названием "NtElevation", которые отвечают за повышение привилегий имплантата, запущенного на компьютере жертвы.
Именно эти модули повышения привилегий мы обнаружили, когда запросили глобальную таблицу конфигурации Jian. И они были не одни. Мы также нашли еще пару эксплойтов для повышения локальных привилегий из серии NtElevation.
В то время как эксплойты Eternal * получили много внимания, и это правильно, упоминания эксплойтов NtElevation почему-то отсутствовали. Мы не смогли найти в Интернете ни одной ссылки на существование модуля NtElevation как части арсенала Equation Group или даже как части эксплойтов Shadow Brokers, ни каких-либо ссылок на следующие 4 кодовых названия эксплойтов.
- ElEi
- ErNi
- EpMo
- EpMe
Примечание. Известно, что эксплойты Equation Group имеют кодовые названия, сокращенные с использованием 4 букв. Например, Eternal Blue и Eternal Romance внутренне называются ETBL и ETRO. Точно так же у описанных выше эксплойтов повышения локальных привилегий есть свои собственные кодовые имена, как указано выше.
Несмотря на наши попытки, нам не удалось отследить полные кодовые названия этих эксплойтов. Однако соглашение об именах предполагает, что EpMo и EpMe относятся к одному типу или что они используют уязвимости в одном модуле, как и эксплойты Eternal * (EternalBlue, EternalRomance и т.д.). Этот вывод действительно имеет смысл, поскольку наш единственный поисковый запрос обнаружил оба этих эксплойта.
Когда мы проанализировали DanderSpritz NtElevation API, мы обнаружили проверки, которые каждый модуль развертывает, чтобы объявить, что эксплойт действительно поддерживается. В сочетании с исходными датами исправлений, которые Касперский оценил для двух эксплойтов с Houston Disk, эта новая информация помогла нам лучше оценить внутреннюю работу каждого CVE-ID.
Мы тщательно проанализировали найденные эксплойты и попытались сопоставить каждый файл эксплойта с его соответствующим CVE-ID. Это результаты нашего анализа и наши выводы.
ElEi – CVE-2011-3402
Houston Disk: 3-е место в порядке исполнения.
Поддерживаемые версии DanderSpritz для Windows: от Windows 2000 до Windows 7 включительно.
Эксплойт также содержит дополнительную проверку, датированную win32k.sys до 23 ноября 2011 года. Это явное указание на CVE-2011-3402, единственную уязвимость шрифта, исправленную в декабре 2011 года. Разрыв в датах объясняется тем, что Microsoft скомпилировала пропатченный драйвер в указанную дату.
Нам известно, что CVE-2011-3402 изначально был определен как 0-Day, который использовался в дикой природе, и был обнаружен в Duqu (1.0). В настоящее время мы можем только указать на это интересное совпадение CVE-ID, но мы еще не изучали его дополнительно и не сравнивали два эксплойта, так как эти эксплойты шрифтов выходят за рамки нашего исследования, которое фокусируется на неизвестных эксплойтах DanderSpritz и их подключение к CVE-2017-0005.
Мы рекомендуем это руководство для будущей публикации и приглашаем исследователей безопасности со всего мира изучить эту связь.
ErNi – CVE-2013-3128
Houston Disk: 2-е место в порядке исполнения.
Поддерживаемые версии DanderSpritz для Windows: только Windows 2000.
Эксплойт также содержит дополнительную проверку того, что ATMFD.dll имеет точную версию "5.0.2.227". Поскольку эксплойт Houston Disk поддерживает дополнительные версии, мы не совсем уверены, почему диапазон версий был сужен в DanderSpritz. По сравнению с ElEi, нет ориентировочной проверки патчей, что может быть связано с тем, что файлы DanderSpritz датированы серединой 2013 года, то есть до патча, который был идентифицирован Kaspersky и датирован октябрем 2013 года.
Мы выбрали CVE-2013-3128 вместо CVE-2013-3894, потому что эта уязвимость является уязвимостью OpenType Font, которая коррелирует с используемым эксплойтом. К этой идентификации следует относиться с недоверием, поскольку ни один из этих идентификаторов CVE на самом деле не был помечен как "эксплуатируемый в дикой природе". Причина, по которой мы выбрали этот CVE-ID, заключается просто в том, что он упоминается во вторник патчей, на который ссылается Касперский. Как и в случае с ElEi, дальнейшее изучение уязвимостей этих шрифтов более чем приветствуется.
Драйвер принтера пользовательского режима (UMPD) 101
Базовый анализ EpMo и EpMe показал, что они связаны с GDI User-Mode-Print-Driver (UMPD), что объясняет, почему мы нашли их при поиске артефакта, связанного с GDI UMPD. Перед тем, как погрузиться в эксплойты, мы сначала расскажем, что такое User-Mode-Print-Driver.
Операционная система Windows поддерживает возможность визуализации большей части необходимой графики для данного задания печати в пользовательском режиме, в отличие от традиционной реализации таких драйверов внутри ядра Windows. Архитектура развертывания такого драйвера печати пользовательского режима (UMPD) показана ниже.
Поддержка такого потока данных требует, чтобы ядро знало об устройстве UMPD пользователя и могло пересылать ему набор запросов в зависимости от типов, которые драйвер объявил для поддержки. Как более подробно объясняется в этом превосходном выступлении Black Hat Europe 2020 (https://i.blackhat.com/eu-20/Wednes...-Vulnerabilities-In-Modern-Windows-Kernel.pdf), посвященном UMPD, разрешение обратных вызовов пользовательского режима, вызываемых из ядра, является верным рецептом для уязвимостей.
В следующих нескольких разделах мы подробно объясним, как каждый эксплойт Equation Group использует UMPD и какие уязвимости в этом механизме были использованы.
EpMo – Анализ
Houston Disk: N/A.
Поддержка DanderSpritz Windows Versions: Windows 2000 до Windows Server 2008 R2, включительно.
Основная причина
После того как мы закончили реверс инжиниринг контекста и утилит, представленных как часть фреймворка и API DanderSpritz, сама уязвимость оказалась довольно простой. Краткий анализ показал, что это, вероятно, уязвимость NULL-Deref, поскольку NULL-страница выделяется, и шелл-код немедленно копируется на нее, как можно увидеть ниже:
Поскольку это уязвимость NULL-Deref, мы можем сразу исключить CVE-2017-0005, поскольку трассировка стека, показанная в блоге Microsoft, не имеет ничего общего со страницей NULL. Это означает, что возможно есть, еще одна уязвимость, обнаруженная и эксплуатируемая Equation Group в 2013 году. Теперь пора понять, что вызывает эту уязвимость NULL-Deref.
Наш первый намек на идентичность затронутого модуля, который, как мы ожидаем, будет UMPD, можно найти в этом классическом примере использования поля перечисления версии ОС:
После получения зависимого от версии индекса обратного вызова сам обратный вызов заменяется фальшивым обратным вызовом злоумышленника ClientPrinterThunk.
Бинго! Эксплойт действительно использует поддельный ClientPrinterThunk. Давайте углубимся и проанализируем логику эксплойта внутри этого фальшивого обратного вызова.
Сам обратный вызов представляет собой тонкую обертку, которая пересылает gdi_ctx и исходный аргумент функции, которая очень похожа на собственный GdiPrinterThunk Windows. Фактически, код эксплойта очень модульный, и каждая команда поддерживаемого драйвера обрабатывается собственным виртуальным обработчиком, реализованным в классе gdi_ctx. Помимо выбранного набора реализованных обработчиков, в этой функции нет реальной логики.
Анализируя эту функцию, мы наткнулись на массив конфигурации GDI, который изначально указывал нам на этот образец эксплойта. Теперь, помещенные в правильный контекст, мы можем легко определить роль этого массива конфигурации. Он содержит значение INDEX_LAST драйвера печати для каждой версии целевой операционной системы.
Как видно выше, это значение конфигурации имеет решающее значение для логики драйвера, поскольку оно представляет общее количество отправленных функций, которые должны обрабатываться драйвером.
Теперь, когда мы поняли общий ход эксплойта и структуру драйвера печати пользовательского режима (UMPD), выявление основной причины уязвимости оказалось относительно простой задачей. В драйвере реализованы специальные обработчики только для следующих основных типов команд:
Помимо этих команд существует еще одна поддерживаемая команда со значением INDEX_LAST + 4, зависящим от операционной системы:
В этой команде мы инициализируем массив, который сообщает операционной системе, какие обработчики функций мы поддерживаем. Злоумышленники отметили все функции как поддерживаемые, за исключением трех обработчиков конкретных функций:
DrvStartDoc (0x23)
DrvEnableSurface (0x03)
DrvDisableSurface (0x04)
Обратите особое внимание на DrvEnableSurface. Системный вызов, запускающий уязвимость, - это NtGdiStartDoc, который отвечает за запуск задания на печать. Однако для этого вызывается уязвимая функция win32k! PDEVOBJ::bMakeSurface(), которая пытается создать поверхность, в точности та операция, которая не поддерживается нашим драйвером. Вот результат отладки уязвимой функции:
Хотя запись DrvDisablePDEV (0x02) существует и указывает на правильную функцию Windows, соседняя запись DrvEnableSurface (0x03) содержит только нули.
С этого момента уязвимость очевидна. Уязвимая функция предполагает, что наш драйвер поддерживает этот обработчик, извлекает пустую запись из структуры и вызывает NULL как функцию, отвечающую за включение поверхности. На рисунке ниже показана полная трассировка стека, прямо в той точке, в которой поток управления передается шеллкоду, который злоумышленник сохранил по адресу 0x0:
Патч
Microsoft устранила эту уязвимость в мае 2017 года, через месяц после утечки Lost in Translation Shadow Brokers. Однако нам не удалось найти CVE-ID, относящийся к этому исправлению. Сам патч устраняет точную ошибку в уязвимой функции win32k!PDEVOBJ::bMakeSurface(). Он добавляет проверку работоспособности после того, как обработчик извлекается из структуры и до того, как он будет вызван функцией. Если запись NULL, функция прерывается.
В заключение, эксплойт EpMo Equation Group является NULL-Deref в модуле GDI UMPD и, следовательно, не является эксплойтом для CVE-2017-0005. Он был пропатчен Microsoft в мае 2017 года, и мы не смогли найти связанного с ним четкого идентификатора CVE.
Теперь, когда мы лучше понимаем API фреймворка и лучше понимаем модуль UMPD, пора сосредоточиться на следующем эксплойте — EpMe.
Напомним, мы обнаружили оба этих эксплойта при поиске артефакта от Jian, эксплойта APT31 для CVE-2017-0005. Поскольку EpMo - это другая уязвимость, которая проистекает из того же модуля, мы надеялись, что EpMe действительно использует CVE-2017-0005.
Время проанализировать это и выяснить.
EpMe – Анализ
Houston Disk: N/A.
Поддержка DanderSpritz : Windows XP до Windows 8, включительно.
Основная причина
Вооружившись новыми знаниями о модуле UMPD, мы начали анализ эксплойта EpMe. Сам эксплойт имеет много общего с EpMo кода, что позволяет нам легко сосредоточиться на специфической для эксплойта логике, уникальной для EpMe. Хотя фаза инициализации этого эксплойта более продолжительна и включает в себя множество операций начальной загрузки, связанных с GDI (DrawStream(), поиск нужного дисплея и т.д.), реальный поток, который захватывает поток управления, относительно прост.
После завершения начальной загрузки эксплойт вызывает системный вызов NtGdiBitBlt. Это инициирует цепочку событий в ядре Windows и в конечном итоге передает поток обратно нашему обратному вызову пользовательского режима (DrvBitBlt ()), зарегистрированному нашим UMPD. В этом суть эксплоита.
Наша функция выделяет новую Rbrush с помощью NtGdiBRUSHOBJ_pvAllocRbrush(), единственная цель которой - позволить реализациям UMPD выделить себе Rbrush и связать ее с BRUSHOBJ. Как прямой результат, это также означает, что Rbrush выделяется в пользовательском режиме с использованием EngAllocUserMemEx (). Сохранение его в пользовательском режиме означает, что мы можем получить к нему доступ и создать содержимое структуры. Итак, злоумышленники повредили Rbrush, указав на набор поддельных объектов GDI, которые были подделаны в локальном буфере стека внутри обратного вызова.
Чтобы перехватить поток управления, злоумышленники решили использовать Palette и создали ее таким образом, чтобы PALETTE.pfnGetNearestFromPalentry указывал на их шелл-код, в точности как Microsoft указала в своем блоге на эксплойт "пойманный в дикой природе". После того, как все построено, обратный вызов вызывает системный вызов NtGdiEngBitBlt с параметром rop4, равным 0xCCAA. Этот конкретный системный вызов был выбран из-за двух ключевых особенностей:
- Пользователь передает ему BRUSHOBJ.
- Значение rop4 0xCCAA означает, что ядро напрямую обращается к управляемой пользователем Rbrush из предоставленного BRUSHOBJ.
В частности, Stream извлекается из полностью контролируемого Rbrush и направляется в EngDrawStream(), в результате чего ничего не подозревающая функция ядра использует наш полностью созданный Stream.
Эта цепочка функций постепенно использует все объекты GDI, которые мы создали в нашем обратном вызове пользовательского режима, что в конечном итоге приводит к XLATEOBJ_iXlate(). Эта последняя функция вызывает созданный нами указатель на функцию PALETTE.pfnGetNearestFromPalentry, таким образом захватывая поток управления и запуская выполнение нашего шелл-кода.
Подводя итог, можно сказать, что основная причина этой уязвимости кроется в сложной конструкции, связанной с поддержкой UMPD, и в необходимости выделять для нее объекты в пользовательском режиме. Сама уязвимость находится внутри EngBitBlt(), который слепо доверяет и напрямую использует созданный нами Rbrush и набор фальшивых объектов GDI, на которые он указывает. Эта уязвимость не только дает злоумышленнику мощный примитив эксплойта, но также указывает на конструктивную проблему в ядре Windows. Пока где-то в ядре есть функция, которая напрямую обращается к предоставленной пользователем Rbrush, она также слепо доверяет всем значениям, на которые она указывает и которые полностью контролируются пользователем.
Патч – CVE-2017-0005
Еще один важный вывод, который мы сделали из анализа эксплуатируемой уязвимости, заключается в том, что теперь мы точно знаем, что EpMe использует CVE-2017-0005. Помимо нашего анализа эксплойтов Equation Group и APT31, эксплойт EpMe идеально согласуется с деталями, опубликованными в блоге Microsoft о CVE-2017-0005. И если этого было недостаточно, эксплойт действительно перестал работать после патча Microsoft, выпущенного в марте 2017 года, исправления, устраняющего указанную уязвимость.
Сам патч довольно прост: EngBitBlt() со значением rop4, равным 0xCCAA, больше не поддерживает возможность рисования Stream, действие, которое требует извлечения Stream из предоставленной пользователем Rbrush. Полностью удалив эту функцию, Microsoft полностью устранила уязвимый поток кода.
До
После
Важно помнить, что два APT, использующие одну и ту же уязвимость (CVE-2017-0005), могут быть просто совпадением. Когда это происходит с исследователями безопасности, такой случай часто называют "столкновением ошибок". Возможно, что исследователи с обеих сторон обнаружили эту уязвимость независимо друг от друга, и это не обязательно означает, что между инструментами существует реальная связь.
Теперь мы сравним два образца эксплойтов, Jian и EpMe, и посмотрим, сможем ли мы обнаружить какую-либо связь между ними, кроме того, что они используют одну и ту же уязвимость.
EpMe vs Jian
Контекст аналогичной версии
В начале нашего исследования мы увидели, что Jian использует контекст, содержащий несколько полей о версии целевой операционной системы. Используемые поля отмечены синим цветом, а неинициализированные поля - красным.
Теперь, когда мы рассматриваем контекст версии, используемый всеми эксплойтами, совместно используемыми фреймворком DanderSpritz, мы можем увидеть следующую, очень похожую структуру:
Поля, отмеченные красным в Jian, были снова отмечены в примере из эксплойтов Equation Group. Как можно видеть, одно поле все еще не используется во всех 4 эксплойтах DanderSpritz, но другое поле активно используется и содержит дескриптор отображенной версии ядра NTOS. Трудно не заметить большое сходство между двумя структурами, вплоть до порядка и размера первых 9 полей, даже включая размер неиспользуемого поля между ними.
Различия между этими двумя структурами конфигурации заключаются в том, что конфигурация Equation Group содержит больше полей, в основном используемых для политик снижения безопасности, которые актуальны для систем Windows 8 и выше. Последнее различие между структурами заключается в поле, определяющем архитектуру целевого ядра, что по какой-то причине было отвергнуто в Jian. Во всяком случае, это поле никогда не использовалось эксплойтом.
В целом, использование контекста версии в эксплойте с китайской-атрибутикой встречается нечасто. Наличие одного, почти идентичного контексту версии, используемому всем модулем DanderSpritz NtElevation, не может быть совпадением.
Та же раскладка памяти
В основе эксплойтов лежит одна функция, которая заполняет буфер различными поддельными объектами GDI, на которые указывает наш объект Rbrush пользовательского режима. Оба эксплойта не только используют одну функцию для создания всех этих фальшивых объектов, но и структура памяти объектов в буфере аргументов также идентична.
Когда мы анализировали код эксплойта Equation Group, мы использовали его для воссоздания исходного кода Proof-Of-Concept (POC). В результате получился следующий украшенный и помеченный код:
За исключением добавленной структуры в конце буфера, которая использует RtlCopyUnicodeString, структура памяти объектов внутри буфера аргументов была полностью идентична.
Поскольку мы также пометили различные объекты, мы можем видеть, что важная часть - это ссылки от одного объекта к другому, а не место, в котором они хранятся в самом буфере. И все же, как по волшебству, оба эксплойта разделяют этот макет памяти.
Разделяемые константы
Еще одно преимущество нашего воссозданного кода POC для EpMe состоит в том, что он позволил нам поиграть с различными константами, используемыми в эксплойте, такими как:
- Имя окна графического интерфейса пользователя - Первоначально «h».
- Пункты локации - одна из которых изначально была (100, 100).
- Идентификатор задания на печать - Изначально 5.
- Имя драйвера/Имя документа - внизу показана странная строка Unicode.
Излишне говорить, что ничего из вышеперечисленного не было связано с самой уязвимостью, и их изменение никак не повлияло на эксплойт. Это просто жестко запрограммированные константы, выбранные исходными разработчиками эксплойта.
Интересно то, что и EpMe, и Jian используют одни и те же жестко запрограммированные константы. Тот факт, что все эти константы являются общими для двух образцов, даже странно выглядящая строка Unicode выше, просто показывает, что один из эксплойтов, скорее всего, был скопирован из другого.
Также возможно, что обе стороны были вдохновлены какой-то неизвестной сторонней реализацией, которая использовала все эти константы. Увы, нам не удалось найти никаких доказательств существования такого модуля. Мы должны сказать, что вероятность этого сценария довольно мала, особенно с учетом странно выглядящей строки Unicode.
Заключительное сравнение
Смысл всего этого довольно прост:
- Один APT обнаружил уязвимость и разработал для нее эксплойт.
- Другой APT захватил эксплоит и воспроизвел для себя.
Хотя оба они заслуживают полной признательности за эти замечательные достижения, мы все же хотим выяснить, кто у кого копировал. Пора сравнить эксплойты.
Кто был первоначальным разработчиком?
Странно выглядящая строка Unicode
По мнению западного исследователя, строка Unicode, используемая как для имени драйвера принтера, так и для имени печатного документа, выглядит чужеродной. И действительно, мы можем с уверенностью сказать, что строка «屁 썟» не выглядит очевидным выбором для носителей английского языка.
Поэтому мы проконсультировались с коллегами по всему миру, которые свободно говорят на китайском, корейском и японском языках, и спросили их мнение об этих двух символах. В единодушном ответе, который мы получили, было заявлено, что не существует языка, на котором эти символы имели бы смысл. В каждом языке только один символ имеет значение и в любом случае не имеет смысла как часть двухсимвольной фразы. Мы также проверили значение символов, созданных путем инвертирования порядка исходных байтов, и результат был таким же.
Так что, вероятно, это не китайская фраза, использованная первоначальными разработчиками эксплойта, но что это такое?
Наша основная гипотеза основана на мнениях разработчиков. Помимо имен файлов DLL и импортированных функций, очень редко можно найти какую-либо строку в образцах Equation Group. Даже имя созданного окна - это всего лишь "h", а не совсем длинная строка, которая могла бы использоваться правилами YARA для «подписи» двоичного файла. Столкнувшись с необходимостью использовать строку Unicode, которая наверняка длиннее одной строки символов ASCII, мы считаем, что разработчики решили использовать шаблон, который соответствует их потребностям:
- Unicode-достаточный для Windows API.
- Не настоящая строка, которую могли бы отследить.
Если мы внимательно посмотрим на выбранную строку Unicode, мы увидим, что на самом деле она имеет больше смысла как фрагмент ассемблера x64:
41 5C pop r12
5F pop rdi
C3 retn
Фактически, эта последовательность байтов является очень популярным фрагментом ассемблера, который встречается почти 150 раз только в ntdll.dll. Выбор такой популярной последовательности для "строки Unicode" позволяет достичь всех заявленных целей.
Наконец, строка также может быть сгенерирована случайным образом и вообще не имеет никакого смысла.
Название окна - «h»
Как мы только что упомянули в предыдущем разделе, имя окна графического интерфейса пользователя, используемое в обоих эксплойтах, - "h". То, что может показаться случайно выбранной короткой строкой, на самом деле имеет за собой определенную историю. Поскольку самая ранняя версия PrivLib, которую нам удалось найти, датируется 2008 годом, все проанализированные нами эксплойты Equation Group использовали одну и ту же строку, когда требовалось имя окна. И эта строка всегда была "h".
Фактически, все 3 эксплойта, включенные в Houston Disk, использовали одну и ту же глобальную строку при создании своего окна:
Это небольшое свидетельство того, что первоначальными авторами эксплойтов действительно могла быть Equation Group. Однако, поскольку этот артефакт также мог быть просто совпадением, теперь мы рассмотрим дополнительные аспекты эксплойтов.
Quirks in Jian
Поддержка Windows 2000
Внимательное изучение уязвимой функции показывает нам, что Windows 2000 никогда не была уязвимой, как можно увидеть ниже:
Несмотря на то, что Windows 2000 не является уязвимой, код UMPD в Jian имеет особые случаи для Windows 2000, а Windows 2000 является частью перечисления версии ОС.
Интересная проблема заключается в том, что согласно конфигурациям эксплойтов Equation Group, EpMe не поддерживает Windows 2000. Минимальная поддерживаемая версия - Windows XP, которая идеально сочетается с уязвимыми версиями Windows.
Тот факт, что Equation Group построил надлежащие фреймворки, означает, что модуль UMPD совместно использовался между EpMe и EpMo. Различия между эксплойтами основаны на логике, специфичной для эксплойтов, которая была реализована внутри виртуальных обработчиков, которые вызываются универсальным модулем UMPD. Поскольку EpMo поддерживает Windows 2000, то же самое делает и модуль UMPD, что объясняет, почему кажется, что EpMe поддерживает эту версию Windows.
Если на мгновение предположить, что APT31 был первоначальным разработчиком эксплойта для CVE-2017-0005, зачем им вообще пытаться добавить поддержку Windows 2000? Windows 2000 никогда не была уязвимой. Чтобы быть ясным, у нас нет никаких указаний на то, что у участников была своя собственная версия эксплойта EpMo или чего-либо подобного, то есть у нас нет никаких указаний на то, что им когда-либо была нужна такая поддержка Windows 2000 для любого другого инструмента/эксплойта.
Гораздо более вероятный сценарий - APT31 скопировал эксплойт из Equation Group. Вполне вероятно, что разработчики угроз, вероятно, не до конца понимали ограничения эксплойта и поэтому оставили код, специфичный для Windows 2000, нетронутым. Старая реликвия, унаследованная от эксплойта EpMo, о котором APT31 даже не подозревал и не заботился.
Ротация значения enum
По какой-то неизвестной причине Jian содержит определения системных вызовов для 32-битного эксплойта, помимо тех, которые необходимы для 64-битного эксплойта. Хотя они не используются на практике, поскольку образец является 64-битным, они все же дают нам представление о том, как бы выглядел их 32-битный эксплойт.
Мы видим, что 32-битная логика Jian для каждого идентификатора системного вызова снова совпадает с логикой Equation Group, вплоть до уровня настройки некоторых идентификаторов на основе мажорного номера пакета обновления.
Проблема в том, что если мы проверим фактические номера системных вызовов для Windows XP Service Pack 0 и Service Pack 1, мы увидим, что условие для установки значения SP_delta некорректно. Это было правильно для эксплойта Equation Group, но неверно здесь, поскольку APT31 изменил значение wSpMajor_refined во время инициализации эксплойта.
Это обновленное значения еще более странно, поскольку в эксплойтах Equation Group о нем вообще не упоминается:
Вы можете спросить: "Зачем кому-то выполнять указанную выше ротацию значений?" Ответ на самом деле довольно прост. Из нашего прошлого анализа нескольких эксплойтов, приписываемых китайским аффилированным лицам, мы увидели, что у разработчиков есть привычка использовать значение 0 в качестве маркера "незаконного значения". Это хорошо видно, поскольку все значения пакета обновления выше 6 отображаются обратно в значение 0, которое отмечает их как "недопустимые". То же самое было и с Enum, которая была полностью увеличена на 1, заставляя Windows NT использовать значение 1 вместо 0 и зарезервировав священное значение 0 для обозначения состояния ошибки.
И все же на этот раз разработчики использовали только частичную ротацию значения пакета обновления, что привело к конфликту с допустимым значением пакета обновления 0, которое по какой-то причине они не переназначили на "1". Это означает, что 0 одновременно является недопустимым значением, которое не должно поддерживаться, и допустимым значением, которое имеет решающее значение для настройки правильных номеров системных вызовов.
Правильная настройка, вероятно, заключалась в том, чтобы увеличить все значения на 1, сопоставить недопустимые значения с 0 и настроить проверку системных вызовов на wSpMajor_refined! = 1.
И снова мы видим странную закономерность. Даже при условии, что китайские эксплойты должны зарезервировать значение 0 для недопустимых значений, код все равно выглядит странным. Разработчик, пишущий этот эксплойт с нуля, вероятно, просто увеличил бы значение wSpMajor_refined на 1, помня, что в будущих проверках Service Pack 0 будет отмечен значением 1. Вместо этого, как бы для того, чтобы не сломать существующий фрагмент кода, инициализация системного вызова по-прежнему проверяет наличие 0, и это значение одновременно и действительное, и недопустимое.
Более вероятное объяснение состоит в том, что исходный код был версией Equation Group, и что разработчики, связанные с китайскими атакующими группами, боялись взломать его, таким образом, сделав только половину в изменении значений. Этот страх взлома кода также отражается на их плохом понимании всего эксплойта.
Строка отладки в функции триггера
Jian содержит отладочную строку "int the overflow !!!" который можно найти в DrvBitBlt() UMPD - функции обратного вызова, ответственной за срабатывание уязвимости.
Как мы уже установили, эксплуатируемая уязвимость не является уязвимостью "переполнения". Хотя строка может намекать либо на "переполнение буфера", либо на "целочисленное переполнение", ни один из них не имеет никакого отношения к проблеме дизайна обратного вызова пользовательского режима, которая фактически использовалась.
Хотя это может быть всего лишь проблема языкового барьера, это еще один возможный признак того, что злоумышленники, стоящие за Jian, не правильно поняли истинную природу эксплуатируемой уязвимости.
Заключение
Вместе с дополнительными артефактами, которые соответствуют артефактам Equation Group, общим для всех эксплойтов даже еще в 2008 году, мы можем с уверенностью заключить следующее:
- Эксплойт EpMe от Equation Group, существующий по крайней мере с 2013 года, является исходным эксплойтом для уязвимости, позже обозначенной как CVE-2017-0005.
- Примерно в 2014 году APT31 удалось захватить как 32-битные, так и 64-битные образцы эксплойта EpMe Equation Group.
- Они скопировали их, чтобы построить Jian, и использовали эту новую версию эксплойта вместе со своим уникальным многоступенчатым упаковщиком.
- Jian был пойман IRT Lockheed Martin и сообщил в Microsoft, которая исправила уязвимость в марте 2017 года и Нарекла ее как CVE-2017-0005.
Тайм-Лайн
Ниже приведена временная шкала событий, связанных с обеими версиями эксплойтов того, что начиналось как EpMe (Equation Group) и в конечном итоге было наречено Microsoft как CVE-2017-0005 (APT31).
Более подробно:
- 2008/2009 - инструменты эксплойтов Early Equation Group: PrivLib/Houston Disk.
- 2013 - эксплойты DanderSpritz NtElevation: ElEi, ErNi, EpMo, EpMe.
- 27 октября 2014 г. - ранняя временная метка из встроенного PE - клонированного EpMe.
- 6 мая 2015 г. - несколько индикаторов того, что полный инструмент APT31 был собран в 2015 году.
- 13 августа 2016 г. - первая публикация Shadow Brokers.
- 8 января 2017 г. - Shadow Brokers допустили утечку структуры каталогов своих файлов, что явно указывает на владение эксплойтами DanderSpritz и Eternal*.
- 14 февраля 2017 г. - вторник исправлений отменен и объединен с мартовскими исправлениями.
- 14 марта 2017 г. - вторник исправлений - исправлены уязвимости CVE-2017-0005 и 1-й раунд критических эксплойтов Equation Group, включенных в подлежащую публикации утечку SB "Lost in Translation".
- 27 марта 2017 г. - Microsoft публикует блог о CVE-2017-0005, о котором сообщил Lockheed Martin, и приписывает его китайскому APT (Zirconium/APT31).
- 14 апреля 2017 г. - опубликована утечка Lost in Translation.
- 9 мая 2017 г. - вторник исправлений: второй раунд исправлений Equation Group включает тихое исправление для эксплойта EpMo Equation Group.
Резюме
Мы начали с анализа "Jian", китайского эксплойта (APT31/Zirconium) для CVE-2017-0005, о котором сообщила группа реагирования на компьютерные инциденты Lockheed Martin. К нашему удивлению, мы обнаружили, что этот эксплойт APT31 на самом деле является реконструированной версией эксплойта Equation Group под названием "EpMe". Это означает, что эксплойт Equation Group в конечном итоге был использован группой, связанной с Китаем, вероятно, против американских целей. Это не первый задокументированный случай китайского APT, использующего 0-Day.
Во-первых, APT3 использовал собственную версию EternalSynergy (называемую UPSynergy) после приобретения эксплойта EternalRomance Equation Group. Однако в случае с UPSynergy наша группа исследователей безопасности, а также Symantec пришли к единому мнению, что китайский эксплойт был воссоздан из перехваченного сетевого трафика.
Случай с EpMe/Jian отличается, поскольку мы ясно показали, что Jian был создан из фактических 32-битных и 64-битных версий эксплойта Equation Group. Это означает, что в этом сценарии китайский APT сам приобрел образцы эксплойтов во всех поддерживаемых ими версиях. Датировав образцы APT31 за 3 года до утечки Lost in Translation от Shadow Broker, мы полагаем, что эти образцы эксплойтов Equation Group могли быть получены китайским APT одним из следующих способов:
При обзоре эксплойтов NtElevation, используемых в постэксплуатационном фрейворке DanderSpritz Equation Group, мы обнаружили 4 эксплойта Windows LPE. Первые два эксплойта NtElevation были уязвимостями шрифтов, которые ранее обсуждались как часть Houston disk (более ранний образец, приписываемый Equation Group). Кроме того, EpMe (CVE-2017-0005) был упомянут и исправлен, когда Jian был захвачен, даже если на тот момент его истинное происхождение еще не было известно.
Наконец, хотя в мае 2017 года Microsoft действительно исправила EpMo, мы не смогли отследить CVE-ID, присвоенный исправленной уязвимости. Мало того, насколько нам известно, наша публикация является первой, в которой даже упоминается о существовании этого эксплойта Equation Group, хотя он был общедоступным на GitHub в течение последних 4 лет.
Это наши новые дополнения к карте атрибутики:
- EpMe (CVE-2017-0005) - эксплойт Equation Group, который был клонирован APT31.
- EpMo - дополнительный эксплойт Equation Group, который ранее никогда не обсуждался.
- Jian - клонированная версия APT31 EpMe, которая была обнаружена IRT Lockheed Martin.
- CVE-2019-0803 - из нескольких источников приписывается "хакеру", спонсируемому государством из Китая. Мы показали, что он использует тот же загрузчик эксплойтов (и API инструмента), что и Jian в APT31.
Источник: https://research.checkpoint.com/2021/the-story-of-jian/
Автор перевода: yashechka
Переведено специально для https://xss.pro
Есть еще одна теория, которая утверждает, что это уже произошло.
Что бы вы сказали, если бы мы сказали вам, что иностранной группе удалось украсть американскую атомную подводную лодку? Это определенно будет плохо и быстро попадет в каждый заголовок газеты.
Однако с кибероружием - хотя его воздействие может быть столь же разрушительным - обычно все обстоит иначе.
Кибероружие является цифровым и нестабильным по своей природе. Чтобы украсть их и переправить с одного континента на другой, достаточно отправить электронное письмо. Они также очень неясны, и их существование является тщательно охраняемым секретом. Именно поэтому, в отличие от атомной подводной лодки, кража кибер-оружия может легко остаться незамеченной и стать фактом, известным лишь немногим избранным.
Последствия такого сценария могут быть разрушительными, поскольку мир уже испытал на себе случай утечки Shadow Brokers, когда таинственная группа решила публично опубликовать широкий спектр кибероружия, предположительно разработанного Tailored Access Operations (TAO) подразделение АНБ - также именуемое "Equation Group". Утечка Shadow Brokers привела к одним из крупнейших кибер-вспышек в истории, самой известной из которых была атака WannaCry, нанесшая сотни миллионов долларов убытков организациям по всему миру, и ее последствия по-прежнему актуальны даже через 3 года после её запуска.
Однако утечка Shadow brokers просто дала нам представление о некоторых возможных последствиях, которые может вызвать такая кибер-кража. Остается еще много важных вопросов - могло ли такое случиться раньше? И если да, то кто за этим стоит и для чего они его использовали?
Наше недавнее исследование направлено на то, чтобы пролить больше света на эту тему и выявить убедительные доказательства того, что такая утечка действительно имела место за годы до утечки Shadow Brokers, в результате чего разработанные в США кибер-инструменты попали в руки китайской группы, которая перепрофилировала их, чтобы атаковать цели США.
Ключевые находки
Введение
В последние несколько месяцев наши исследователи вредоносных программ и уязвимостей сосредоточили внимание на недавних эксплойтах для повышения привилегий Windows, приписываемых китайским хакерам. В ходе этого расследования нам удалось раскрыть скрытую историю "Jian", эксплойта нулевого дня, который ранее приписывался APT31 (Zirconium), и показать его истинное происхождение.
В этом блоге мы показываем, что CVE-2017-0005, уязвимость Windows Local-Privilege-Escalation (LPE), которая была приписана китайскому APT, была реплицирована на основе эксплойта Equation Group для той же уязвимости, к которой APT смог получить доступ. EpMe, эксплойт Equation Group для CVE-2017-0005, является одним из 4 различных эксплойтов LPE, включенных в структуру фреймворка DanderSpritz. EpMe восходит как минимум к 2013 году - за четыре года до того, как APT31 был пойман на использовании этой уязвимости в дикой природе.
Это не первый задокументированный случай, когда китайский APT перепрофилировал эксплойт Equation Group. В случае с Bemstour, который обсуждали как Symantec, так и наша собственная исследовательская группа, основное предположение заключалось в том, что APT3 (Buckeye) проснифал эксплойт EternalRomance из сетевого трафика, а затем обновил его до эквивалента EternalSynergy, используя дополнительную уязвимость APT3. Однако в данном случае у нас есть веские доказательства того, что APT31 имел доступ к фактическим файлам эксплойтов Equation Group как в 32-битной, так и в 64-битной версиях.
В следующих разделах мы представляем 4 различных эксплойта Windows LPE, включенных в фреймворк DanderSpritz, и раскрываем дополнительный код эксплойта под названием "EpMo". Этот эксплойт был пропатчен в мае 2017 года, вероятно, как часть последующих исправлений утечки Shadow Brokers "Lost in Translation" инструментов Equation Group. Хотя уязвимость была исправлена, нам не удалось идентифицировать связанный с ней CVE-ID. Насколько нам известно, это первое публичное упоминание о существовании этой дополнительной уязвимости Equation Group.
Background
В рамках нашего постоянного исследования эксплойтов Windows LPE и отслеживания авторов эксплойтов мы начали анализировать эксплойты, приписываемые китайским APT. Поскольку CVE-2019-0803 недавно был упомянут в списке 25 основных уязвимостей АНБ, используемых китайскими хакерами, мы решили, что это хорошее место для начала. После того, как мы закончили документирование всей информации, которую мы собрали об этом уникальном эксплойте, который первоначально был связан с китайскими хакерами, мы перешли к следующему эксплойту с китайской атрибутикой в нашем списке: CVE-2017-0005.
В нашем обзоре отчета Microsoft об уязвимости, которая была обнаружена в открытом доступе и приписывалась Zirconium (APT31), мы обнаружили несколько интересных деталей:
Вооруженные этими двумя зацепками и уже знакомые с упаковщиком, используемым этими эксплойтами, мы приступили к поиску описанного эксплойта CVE-2017-0005.
Получив 64-битный образец эксплойта CVE-2017-0005, мы проверили его на соответствие информации, описанной Microsoft в их блоге. Мало того, что это совпадало, при игнорировании случайного распределения страниц оба образца использовали одни и те же адреса (те же самые младшие 3 полубайта).
Сравнение CVE-2017-0005 и CVE-2019-0803
В следующем разделе мы подробно опишем некоторые характеристики упаковщика и загрузчика, используемых в CVE-2017-0005 и CVE-2019-0803, и подчеркнем их общие черты и различия.
Jian, эксплойт CVE-2017-0005, поставлялся в виде DLL с именем Add.dll. Он содержал интересный путь PDB, предполагающий, что он был написан в 2015 году в рамках проекта под названием "rundll32_getadmin".
F:\\code\\2015\\rundll32_getadmin\\Add\\x64\\Release\\Add.pdb
Когда мы проверили метку даты и времени двоичного файла в заголовке файла, мы увидели, что DLL была скомпилирована 6 мая, в среду, 02:08:24 2015 г., что хорошо согласуется с именем папки из PDB. Дополнительная отметка времени в каталоге экспорта указывает на ту же дату. Говоря о каталоге экспорта, DLL имеет единственную экспортируемую функцию с именем "AddByGod|, которая, как мы вскоре узнаем, является функцией входа для упаковщика.
Процедура дешифрования очень проста. Упаковщик начинает с выделения памяти для зашифрованного кода и копирует его во вновь выделенный буфер. Затем он выделяет буфер с защитой PAGE_EXECUTE_READWRITE для хранения расшифрованного кода. После распределения буферов упаковщик проверяет, был ли передан строковый аргумент, который будет использоваться в качестве ключа дешифрования, в функцию AddByGod. Затем упаковщик использует алгоритм AES256 с ключом, полученным из SHA1 переданного аргумента, для расшифровки зашифрованного кода. Если расшифровка прошла успешно, выполняется расшифрованный код и запускаются полезные данные второго этапа. К счастью, нам удалось получить пароль, необходимый для выполнения двоичного файла и дешифрования зашифрованных данных.
rundll32.exe Add.dll AddByGod [password]
Второй этап начинается с типичной техники шелл-кода, поиска в заголовке модуля адреса kernel32.dll и динамического получения указателя на функцию экспорта GetProcAddress. Затем программа распаковывает другой переносимый исполняемый файл (PE) и переходит к его точке входа. Распакованный PE, который является 3-м этапом в последовательности загрузки, имеет намеренно поврежденные заголовки. Он выполняет базовые операции загрузки, а затем начинается с рефлексивной загрузки встроенного исполняемого файла (да, еще одного). Загруженный PE является последним этапом в последовательности загрузки и отвечает за выполнение эксплойта.
Интересно отметить, что время компиляции встроенного двоичного файла - самого эксплойта - датируется октябрем 2014 года. Это говорит о том, что злоумышленники использовали этот зеро-дэй в 2014 году, почти за три года до того, как он стал общедоступным в утечке Shadow Brokers и был исправлен Microsoft.
Как видно на рисунке выше, упаковщик, используемый для CVE-2019-0803, очень похож на упаковщик, используемый в CVE-2017-0005. На самом деле поток практически идентичен. Файл был скомпилирован 18 сентября 2018 г. и также имеет внутреннее имя "Add.dll". Как и ранее упакованный эксплойт, CVE-2019-0803 также имеет функцию экспорта с именем "AddByGod" и содержит отладочную информацию:
C:\Users\sms2056\Desktop\Add（未修改dll‘）\x64\Release\Add.pdb
В отличие от предыдущего примера, в этом примере используется другой пароль для дешифрования, и при запуске требуется дополнительный аргумент (используется на более поздних этапах). Затем поток выполнения продолжается точно так же, как мы наблюдали в предыдущем примере, за одним исключением: после того, как программа распаковывает полезную нагрузку PE и переходит к своей точке входа, у нее нет 4-го этапа другого встроенного PE, а просто начинается этап эксплуатации.
Мы искали другие образцы, в которых используется этот или аналогичный вариант описанного нами упаковщика, и обнаружили несколько образцов и семейств вредоносных программ, которые использовали его в течение многих лет. Все вредоносные программы явно и исключительно приписываются китайским группам атак. Добавление этого вывода к имеющейся у нас контекстной информации, независимой атрибуции Microsoft CVE-2017-0005 китайской APT и атрибутикой NSA CVE-2019-0803 "китайским государственным спонсорам" заставляет нас полагать, что эксплойт CVE-2017-0005 действительно использовался злоумышленниками, входящими в состав китайской группировки.
Jian – CVE-2017-0005
Анализируя Jian, мы заметили следующие интересные особенности.
Контекст версия операционной системы
Эксплойт создает контекст расширенной версии, который включает в себя несколько полей, каждое из которых представляет различные характеристики целевой операционной системы. Этот обширный контекст не типичен для китайских эксплойтов, которые мы проанализировали ранее, и выглядит как своего рода утилита/фреймворк. Это еще более подозрительно, поскольку некоторые поля в контексте даже не инициализированы (отмечены красным), а в целом только три из них используются самим эксплойтом (отмечены синим).
Для сравнения: эксплойт CVE-2019-0803 поддерживал только одну версию Windows и использовал жестко запрограммированные зависящие от версии константы для Windows Server 2008 R2. Alibaba даже сообщила, что имя файла инструмента было 2008.dll, что не оставляло сомнений в его предназначении.
Таблица глобальной конфигурации
Перечисление версий ОС используется в качестве индекса для глобальной таблицы конфигурации. Это классический пример использования такого перечисления, когда требуется конфигурация, зависящая от версии. Сама таблица конфигурации выглядит как многообещающий артефакт, который может появиться в дополнительных эксплойтах тех же авторов.
Мы создали сигнатуры обнаружения и искали образцы, содержащие эту таблицу конфигурации. По нашему поисковому запросу были получены следующие образцы:
Соглашение об именах файлов и их контекст сразу же застали нас врасплох. Мы признали их частью утечки инструментов Equation Group, произведенной Shadow Brokers. Equation Group - это название, данное группе APT, которая считается подразделением Tailored Access Operations (TAO) Агентства национальной безопасности США. Как наш поиск чрезвычайно уникальных артефактов, извлеченных из китайского эксплойта нулевого дня, исправленного в марте 2017 года, показал результаты утечки инструментов Equation Group с 2013 года? Чтобы ответить на этот вопрос, мы начали углубляться и анализировать найденную информацию.
Lost In Translation
Прежде чем описывать наш анализ, мы хотим дать краткую историю группы The Shadow Brokers и их утечки инструментов Equation Group. Мы считаем, что понимание природы утечки, и особенно графика, имеет решающее значение для понимания того, что произошло дальше.
Shadow Brokers - это загадочная группа хакеров, впервые появившаяся 12 августа 2016 года, когда они пригласили общественность принять участие в аукционе "Кибероружия" Equation Group. С тех пор группа начала выпускать все больше и больше файлов в течение нескольких месяцев. Одна из этих утечек, получившая название Lost in Translation, появилась в апреле 2017 года и хорошо известна тем, что выпустила печально известные эксплойты Equation Group, такие как Eternal Blue.
Одним из основных компонентов этой утечки является DanderSpritz, фреймворк пост-эксплуатации Equation Group, который содержит широкий спектр инструментов для постоянства, разведки, бокового перемещения, обхода антивирусных механизмов и т.д. Структура очень модульная и предоставляет оператору множество возможностей для доступа к компьютерам жертв. В течение последних месяцев мы пересмотрели фреймворк DanderSpritz, реконструировали некоторые из его модулей и имплантатов и планируем опубликовать подробную публикацию, посвященную фреймворку и нашим открытиям.
Наш проект профилирования авторов эксплойтов фокусируется на эксплойтах Windows LPE, таких как CVE-2017-0005, артефакты которых мы искали. Как это часто бывает во фреймворках пост-эксплуатации, DanderSpritz и утечка Lost In Translation также содержат эксплойты LPE, и два из них соответствуют нашему запросу.
Теперь мы представляем краткий обзор некоторых эксплойтов LPE, которые были приписаны Equation Group, и их связи с просочившейся структурой DanderSpritz.
История эксплойтов Equation Group LPE
PrivLib и Houston Disk
Термин "PrivLib" часто используется для обозначения модуля повышения привилегий, встроенного в данный имплант Equation Group. PrivLib содержит выбранный набор эксплойтов Windows LPE, выбранных из арсенала Equation Group, и все они заключены в тонкую оболочку, известную своим уникальным мьютексом prkMtx.
В 2015 году Касперский сообщил о наборе Windows LPE, встроенных в booby-trapped диск, который был передан на научном съезде в Хьюстоне. Все эксплойты, приписываемые Equation Group, были зеродеями на момент разработки, а некоторые даже датировались 2008 годом. В общем, диск Houston Disk содержал версию PrivLib, которая запускает набор из 3 эксплойтов один за другим, пока не будут получены желаемые привилегии.
Вот список эксплойтов, содержащихся на диске, в соответствии с порядком их выполнения:
- MS09-025 (Fanny / Stuxnet)
- CVE-2013-3128
- CVE-2011-3402
Примечание. Перечисленные здесь CVE не совпадают с теми, которые изначально были упомянуты "Лабораторией Касперского" в своем отчете. Во-первых, исследователи Касперского с самого начала не были уверены в идентификаторах CVE-ID, отметив их как "возможно". Во-вторых, мы нашли дополнительную информацию о последних двух эксплойтах, которая помогла пролить свет на более вероятные идентификаторы CVE для каждого из них. Более подробную информацию об идентификации CVE-ID можно найти позже в соответствующих разделах, описывающих каждый эксплойт.
DanderSpritz NtElevation
DanderSpritz - это модульный фреймворк пост-эксплуатации, который содержит десятки различных взаимозависимых модулей. Например, некоторые модули не запускаются, если сначала не выполняются определенные модули, а для других требуются особые привилегии или артефакты. Для запуска некоторых модулей требуются привилегии учетной записи SYSTEM. Для этого DanderSpritz запускает набор модулей под названием "NtElevation", которые отвечают за повышение привилегий имплантата, запущенного на компьютере жертвы.
Именно эти модули повышения привилегий мы обнаружили, когда запросили глобальную таблицу конфигурации Jian. И они были не одни. Мы также нашли еще пару эксплойтов для повышения локальных привилегий из серии NtElevation.
В то время как эксплойты Eternal * получили много внимания, и это правильно, упоминания эксплойтов NtElevation почему-то отсутствовали. Мы не смогли найти в Интернете ни одной ссылки на существование модуля NtElevation как части арсенала Equation Group или даже как части эксплойтов Shadow Brokers, ни каких-либо ссылок на следующие 4 кодовых названия эксплойтов.
- ElEi
- ErNi
- EpMo
- EpMe
Примечание. Известно, что эксплойты Equation Group имеют кодовые названия, сокращенные с использованием 4 букв. Например, Eternal Blue и Eternal Romance внутренне называются ETBL и ETRO. Точно так же у описанных выше эксплойтов повышения локальных привилегий есть свои собственные кодовые имена, как указано выше.
Несмотря на наши попытки, нам не удалось отследить полные кодовые названия этих эксплойтов. Однако соглашение об именах предполагает, что EpMo и EpMe относятся к одному типу или что они используют уязвимости в одном модуле, как и эксплойты Eternal * (EternalBlue, EternalRomance и т.д.). Этот вывод действительно имеет смысл, поскольку наш единственный поисковый запрос обнаружил оба этих эксплойта.
Когда мы проанализировали DanderSpritz NtElevation API, мы обнаружили проверки, которые каждый модуль развертывает, чтобы объявить, что эксплойт действительно поддерживается. В сочетании с исходными датами исправлений, которые Касперский оценил для двух эксплойтов с Houston Disk, эта новая информация помогла нам лучше оценить внутреннюю работу каждого CVE-ID.
Мы тщательно проанализировали найденные эксплойты и попытались сопоставить каждый файл эксплойта с его соответствующим CVE-ID. Это результаты нашего анализа и наши выводы.
ElEi – CVE-2011-3402
Houston Disk: 3-е место в порядке исполнения.
Поддерживаемые версии DanderSpritz для Windows: от Windows 2000 до Windows 7 включительно.
Эксплойт также содержит дополнительную проверку, датированную win32k.sys до 23 ноября 2011 года. Это явное указание на CVE-2011-3402, единственную уязвимость шрифта, исправленную в декабре 2011 года. Разрыв в датах объясняется тем, что Microsoft скомпилировала пропатченный драйвер в указанную дату.
Нам известно, что CVE-2011-3402 изначально был определен как 0-Day, который использовался в дикой природе, и был обнаружен в Duqu (1.0). В настоящее время мы можем только указать на это интересное совпадение CVE-ID, но мы еще не изучали его дополнительно и не сравнивали два эксплойта, так как эти эксплойты шрифтов выходят за рамки нашего исследования, которое фокусируется на неизвестных эксплойтах DanderSpritz и их подключение к CVE-2017-0005.
Мы рекомендуем это руководство для будущей публикации и приглашаем исследователей безопасности со всего мира изучить эту связь.
ErNi – CVE-2013-3128
Houston Disk: 2-е место в порядке исполнения.
Поддерживаемые версии DanderSpritz для Windows: только Windows 2000.
Эксплойт также содержит дополнительную проверку того, что ATMFD.dll имеет точную версию "5.0.2.227". Поскольку эксплойт Houston Disk поддерживает дополнительные версии, мы не совсем уверены, почему диапазон версий был сужен в DanderSpritz. По сравнению с ElEi, нет ориентировочной проверки патчей, что может быть связано с тем, что файлы DanderSpritz датированы серединой 2013 года, то есть до патча, который был идентифицирован Kaspersky и датирован октябрем 2013 года.
Мы выбрали CVE-2013-3128 вместо CVE-2013-3894, потому что эта уязвимость является уязвимостью OpenType Font, которая коррелирует с используемым эксплойтом. К этой идентификации следует относиться с недоверием, поскольку ни один из этих идентификаторов CVE на самом деле не был помечен как "эксплуатируемый в дикой природе". Причина, по которой мы выбрали этот CVE-ID, заключается просто в том, что он упоминается во вторник патчей, на который ссылается Касперский. Как и в случае с ElEi, дальнейшее изучение уязвимостей этих шрифтов более чем приветствуется.
Драйвер принтера пользовательского режима (UMPD) 101
Базовый анализ EpMo и EpMe показал, что они связаны с GDI User-Mode-Print-Driver (UMPD), что объясняет, почему мы нашли их при поиске артефакта, связанного с GDI UMPD. Перед тем, как погрузиться в эксплойты, мы сначала расскажем, что такое User-Mode-Print-Driver.
Операционная система Windows поддерживает возможность визуализации большей части необходимой графики для данного задания печати в пользовательском режиме, в отличие от традиционной реализации таких драйверов внутри ядра Windows. Архитектура развертывания такого драйвера печати пользовательского режима (UMPD) показана ниже.
Поддержка такого потока данных требует, чтобы ядро знало об устройстве UMPD пользователя и могло пересылать ему набор запросов в зависимости от типов, которые драйвер объявил для поддержки. Как более подробно объясняется в этом превосходном выступлении Black Hat Europe 2020 (https://i.blackhat.com/eu-20/Wednes...-Vulnerabilities-In-Modern-Windows-Kernel.pdf), посвященном UMPD, разрешение обратных вызовов пользовательского режима, вызываемых из ядра, является верным рецептом для уязвимостей.
В следующих нескольких разделах мы подробно объясним, как каждый эксплойт Equation Group использует UMPD и какие уязвимости в этом механизме были использованы.
EpMo – Анализ
Houston Disk: N/A.
Поддержка DanderSpritz Windows Versions: Windows 2000 до Windows Server 2008 R2, включительно.
Основная причина
После того как мы закончили реверс инжиниринг контекста и утилит, представленных как часть фреймворка и API DanderSpritz, сама уязвимость оказалась довольно простой. Краткий анализ показал, что это, вероятно, уязвимость NULL-Deref, поскольку NULL-страница выделяется, и шелл-код немедленно копируется на нее, как можно увидеть ниже:
Поскольку это уязвимость NULL-Deref, мы можем сразу исключить CVE-2017-0005, поскольку трассировка стека, показанная в блоге Microsoft, не имеет ничего общего со страницей NULL. Это означает, что возможно есть, еще одна уязвимость, обнаруженная и эксплуатируемая Equation Group в 2013 году. Теперь пора понять, что вызывает эту уязвимость NULL-Deref.
Наш первый намек на идентичность затронутого модуля, который, как мы ожидаем, будет UMPD, можно найти в этом классическом примере использования поля перечисления версии ОС:
После получения зависимого от версии индекса обратного вызова сам обратный вызов заменяется фальшивым обратным вызовом злоумышленника ClientPrinterThunk.
Бинго! Эксплойт действительно использует поддельный ClientPrinterThunk. Давайте углубимся и проанализируем логику эксплойта внутри этого фальшивого обратного вызова.
Сам обратный вызов представляет собой тонкую обертку, которая пересылает gdi_ctx и исходный аргумент функции, которая очень похожа на собственный GdiPrinterThunk Windows. Фактически, код эксплойта очень модульный, и каждая команда поддерживаемого драйвера обрабатывается собственным виртуальным обработчиком, реализованным в классе gdi_ctx. Помимо выбранного набора реализованных обработчиков, в этой функции нет реальной логики.
Анализируя эту функцию, мы наткнулись на массив конфигурации GDI, который изначально указывал нам на этот образец эксплойта. Теперь, помещенные в правильный контекст, мы можем легко определить роль этого массива конфигурации. Он содержит значение INDEX_LAST драйвера печати для каждой версии целевой операционной системы.
Как видно выше, это значение конфигурации имеет решающее значение для логики драйвера, поскольку оно представляет общее количество отправленных функций, которые должны обрабатываться драйвером.
Теперь, когда мы поняли общий ход эксплойта и структуру драйвера печати пользовательского режима (UMPD), выявление основной причины уязвимости оказалось относительно простой задачей. В драйвере реализованы специальные обработчики только для следующих основных типов команд:
Помимо этих команд существует еще одна поддерживаемая команда со значением INDEX_LAST + 4, зависящим от операционной системы:
В этой команде мы инициализируем массив, который сообщает операционной системе, какие обработчики функций мы поддерживаем. Злоумышленники отметили все функции как поддерживаемые, за исключением трех обработчиков конкретных функций:
DrvStartDoc (0x23)
DrvEnableSurface (0x03)
DrvDisableSurface (0x04)
Обратите особое внимание на DrvEnableSurface. Системный вызов, запускающий уязвимость, - это NtGdiStartDoc, который отвечает за запуск задания на печать. Однако для этого вызывается уязвимая функция win32k! PDEVOBJ::bMakeSurface(), которая пытается создать поверхность, в точности та операция, которая не поддерживается нашим драйвером. Вот результат отладки уязвимой функции:
Хотя запись DrvDisablePDEV (0x02) существует и указывает на правильную функцию Windows, соседняя запись DrvEnableSurface (0x03) содержит только нули.
С этого момента уязвимость очевидна. Уязвимая функция предполагает, что наш драйвер поддерживает этот обработчик, извлекает пустую запись из структуры и вызывает NULL как функцию, отвечающую за включение поверхности. На рисунке ниже показана полная трассировка стека, прямо в той точке, в которой поток управления передается шеллкоду, который злоумышленник сохранил по адресу 0x0:
Патч
Microsoft устранила эту уязвимость в мае 2017 года, через месяц после утечки Lost in Translation Shadow Brokers. Однако нам не удалось найти CVE-ID, относящийся к этому исправлению. Сам патч устраняет точную ошибку в уязвимой функции win32k!PDEVOBJ::bMakeSurface(). Он добавляет проверку работоспособности после того, как обработчик извлекается из структуры и до того, как он будет вызван функцией. Если запись NULL, функция прерывается.
В заключение, эксплойт EpMo Equation Group является NULL-Deref в модуле GDI UMPD и, следовательно, не является эксплойтом для CVE-2017-0005. Он был пропатчен Microsoft в мае 2017 года, и мы не смогли найти связанного с ним четкого идентификатора CVE.
Теперь, когда мы лучше понимаем API фреймворка и лучше понимаем модуль UMPD, пора сосредоточиться на следующем эксплойте — EpMe.
Напомним, мы обнаружили оба этих эксплойта при поиске артефакта от Jian, эксплойта APT31 для CVE-2017-0005. Поскольку EpMo - это другая уязвимость, которая проистекает из того же модуля, мы надеялись, что EpMe действительно использует CVE-2017-0005.
Время проанализировать это и выяснить.
EpMe – Анализ
Houston Disk: N/A.
Поддержка DanderSpritz : Windows XP до Windows 8, включительно.
Основная причина
Вооружившись новыми знаниями о модуле UMPD, мы начали анализ эксплойта EpMe. Сам эксплойт имеет много общего с EpMo кода, что позволяет нам легко сосредоточиться на специфической для эксплойта логике, уникальной для EpMe. Хотя фаза инициализации этого эксплойта более продолжительна и включает в себя множество операций начальной загрузки, связанных с GDI (DrawStream(), поиск нужного дисплея и т.д.), реальный поток, который захватывает поток управления, относительно прост.
После завершения начальной загрузки эксплойт вызывает системный вызов NtGdiBitBlt. Это инициирует цепочку событий в ядре Windows и в конечном итоге передает поток обратно нашему обратному вызову пользовательского режима (DrvBitBlt ()), зарегистрированному нашим UMPD. В этом суть эксплоита.
Наша функция выделяет новую Rbrush с помощью NtGdiBRUSHOBJ_pvAllocRbrush(), единственная цель которой - позволить реализациям UMPD выделить себе Rbrush и связать ее с BRUSHOBJ. Как прямой результат, это также означает, что Rbrush выделяется в пользовательском режиме с использованием EngAllocUserMemEx (). Сохранение его в пользовательском режиме означает, что мы можем получить к нему доступ и создать содержимое структуры. Итак, злоумышленники повредили Rbrush, указав на набор поддельных объектов GDI, которые были подделаны в локальном буфере стека внутри обратного вызова.
Чтобы перехватить поток управления, злоумышленники решили использовать Palette и создали ее таким образом, чтобы PALETTE.pfnGetNearestFromPalentry указывал на их шелл-код, в точности как Microsoft указала в своем блоге на эксплойт "пойманный в дикой природе". После того, как все построено, обратный вызов вызывает системный вызов NtGdiEngBitBlt с параметром rop4, равным 0xCCAA. Этот конкретный системный вызов был выбран из-за двух ключевых особенностей:
- Пользователь передает ему BRUSHOBJ.
- Значение rop4 0xCCAA означает, что ядро напрямую обращается к управляемой пользователем Rbrush из предоставленного BRUSHOBJ.
В частности, Stream извлекается из полностью контролируемого Rbrush и направляется в EngDrawStream(), в результате чего ничего не подозревающая функция ядра использует наш полностью созданный Stream.
Эта цепочка функций постепенно использует все объекты GDI, которые мы создали в нашем обратном вызове пользовательского режима, что в конечном итоге приводит к XLATEOBJ_iXlate(). Эта последняя функция вызывает созданный нами указатель на функцию PALETTE.pfnGetNearestFromPalentry, таким образом захватывая поток управления и запуская выполнение нашего шелл-кода.
Подводя итог, можно сказать, что основная причина этой уязвимости кроется в сложной конструкции, связанной с поддержкой UMPD, и в необходимости выделять для нее объекты в пользовательском режиме. Сама уязвимость находится внутри EngBitBlt(), который слепо доверяет и напрямую использует созданный нами Rbrush и набор фальшивых объектов GDI, на которые он указывает. Эта уязвимость не только дает злоумышленнику мощный примитив эксплойта, но также указывает на конструктивную проблему в ядре Windows. Пока где-то в ядре есть функция, которая напрямую обращается к предоставленной пользователем Rbrush, она также слепо доверяет всем значениям, на которые она указывает и которые полностью контролируются пользователем.
Патч – CVE-2017-0005
Еще один важный вывод, который мы сделали из анализа эксплуатируемой уязвимости, заключается в том, что теперь мы точно знаем, что EpMe использует CVE-2017-0005. Помимо нашего анализа эксплойтов Equation Group и APT31, эксплойт EpMe идеально согласуется с деталями, опубликованными в блоге Microsoft о CVE-2017-0005. И если этого было недостаточно, эксплойт действительно перестал работать после патча Microsoft, выпущенного в марте 2017 года, исправления, устраняющего указанную уязвимость.
Сам патч довольно прост: EngBitBlt() со значением rop4, равным 0xCCAA, больше не поддерживает возможность рисования Stream, действие, которое требует извлечения Stream из предоставленной пользователем Rbrush. Полностью удалив эту функцию, Microsoft полностью устранила уязвимый поток кода.
До
После
Важно помнить, что два APT, использующие одну и ту же уязвимость (CVE-2017-0005), могут быть просто совпадением. Когда это происходит с исследователями безопасности, такой случай часто называют "столкновением ошибок". Возможно, что исследователи с обеих сторон обнаружили эту уязвимость независимо друг от друга, и это не обязательно означает, что между инструментами существует реальная связь.
Теперь мы сравним два образца эксплойтов, Jian и EpMe, и посмотрим, сможем ли мы обнаружить какую-либо связь между ними, кроме того, что они используют одну и ту же уязвимость.
EpMe vs Jian
Контекст аналогичной версии
В начале нашего исследования мы увидели, что Jian использует контекст, содержащий несколько полей о версии целевой операционной системы. Используемые поля отмечены синим цветом, а неинициализированные поля - красным.
Теперь, когда мы рассматриваем контекст версии, используемый всеми эксплойтами, совместно используемыми фреймворком DanderSpritz, мы можем увидеть следующую, очень похожую структуру:
Поля, отмеченные красным в Jian, были снова отмечены в примере из эксплойтов Equation Group. Как можно видеть, одно поле все еще не используется во всех 4 эксплойтах DanderSpritz, но другое поле активно используется и содержит дескриптор отображенной версии ядра NTOS. Трудно не заметить большое сходство между двумя структурами, вплоть до порядка и размера первых 9 полей, даже включая размер неиспользуемого поля между ними.
Различия между этими двумя структурами конфигурации заключаются в том, что конфигурация Equation Group содержит больше полей, в основном используемых для политик снижения безопасности, которые актуальны для систем Windows 8 и выше. Последнее различие между структурами заключается в поле, определяющем архитектуру целевого ядра, что по какой-то причине было отвергнуто в Jian. Во всяком случае, это поле никогда не использовалось эксплойтом.
В целом, использование контекста версии в эксплойте с китайской-атрибутикой встречается нечасто. Наличие одного, почти идентичного контексту версии, используемому всем модулем DanderSpritz NtElevation, не может быть совпадением.
Та же раскладка памяти
В основе эксплойтов лежит одна функция, которая заполняет буфер различными поддельными объектами GDI, на которые указывает наш объект Rbrush пользовательского режима. Оба эксплойта не только используют одну функцию для создания всех этих фальшивых объектов, но и структура памяти объектов в буфере аргументов также идентична.
Когда мы анализировали код эксплойта Equation Group, мы использовали его для воссоздания исходного кода Proof-Of-Concept (POC). В результате получился следующий украшенный и помеченный код:
C:
void populate_buffer_and_brush(char * pBuffer, HBRUSH hbrush)
{
memset(pBuffer, 0, 0x200);
memset(&pBuffer[0x200], 0, 0xA8);
memset(&pBuffer[0x2A8], 0, 0x30);
memset(&pBuffer[0x2D8], 0, 0x10);
// 0x00: PALETTE
*(DWORD *)( pBuffer + 0x18) = 2; // 0x14 - 0x1C: flPal
*(size_t *)(pBuffer + 0x80) = pBuffer + 0x2A8; // 0x80 - 0x88: apalColor
// Brush (DRAWSTREAMINFO)
size_t * pBrush = (size_t*)hbrush;
pBrush[3] = pBuffer + 0x29C; // pptlDstOffset - Pointer to 0
pBrush[4] = pBuffer + 0x208; // pxloSrcToBGRA
pBrush[5] = pBuffer + 0x208; // pxloDstToBGRA
pBrush[6] = pBuffer + 0x208; // pxloBGRAToDst <-- We use this one (offset 0x30)
pBrush[7] = 60; // ulStreamLength - 60
pBrush[8] = pBuffer + 0x260; // pvStream - Pointer to our built "Stream"
// Second Struct
*(size_t *)(pBuffer + 0x200) = hbrush;
// 0x208: _XLATE
*(size_t *)(pBuffer + 0x230) = pBuffer; // ppalSrc
*(size_t *)(pBuffer + 0x238) = pBuffer; // ppalDst <-- We use this one (offset 0x30)
*(size_t *)(pBuffer + 0x240) = pBuffer; // ppalDstDC
// 0x260 - 0x2A8: Our "Stream"
*(DWORD *)(pBuffer + 0x260) = 9; // DS_NINEGRIDID (ulCmdID)
*(DWORD *)(pBuffer + 0x26C) = 1; // rclDst.right = 0x01
*(DWORD *)(pBuffer + 0x270) = 1; // rclDst.bottom = 0x01
*(DWORD *)(pBuffer + 0x27C) = 80; // rclSrc.right = 0x50
*(DWORD *)(pBuffer + 0x280) = 80; // rclSrc.bottom = 0x50
*(DWORD *)(pBuffer + 0x284) = 4; // ngi.flFlags := DSDNG_PERPIXELALPHA (4)
// 0x2A8: Palette Color Table
*(DWORD *)(pBuffer + 0x2CC) = 100;
// Fourth Struct
*(size_t *)(pBuffer + 0x2D8) = AllocMemoryPage(0x10000);
*(size_t *)(pBuffer + 0x2E0) = g_pRtlCopyUnicodeString;За исключением добавленной структуры в конце буфера, которая использует RtlCopyUnicodeString, структура памяти объектов внутри буфера аргументов была полностью идентична.
Поскольку мы также пометили различные объекты, мы можем видеть, что важная часть - это ссылки от одного объекта к другому, а не место, в котором они хранятся в самом буфере. И все же, как по волшебству, оба эксплойта разделяют этот макет памяти.
Разделяемые константы
Еще одно преимущество нашего воссозданного кода POC для EpMe состоит в том, что он позволил нам поиграть с различными константами, используемыми в эксплойте, такими как:
- Имя окна графического интерфейса пользователя - Первоначально «h».
- Пункты локации - одна из которых изначально была (100, 100).
- Идентификатор задания на печать - Изначально 5.
- Имя драйвера/Имя документа - внизу показана странная строка Unicode.
Излишне говорить, что ничего из вышеперечисленного не было связано с самой уязвимостью, и их изменение никак не повлияло на эксплойт. Это просто жестко запрограммированные константы, выбранные исходными разработчиками эксплойта.
Интересно то, что и EpMe, и Jian используют одни и те же жестко запрограммированные константы. Тот факт, что все эти константы являются общими для двух образцов, даже странно выглядящая строка Unicode выше, просто показывает, что один из эксплойтов, скорее всего, был скопирован из другого.
Также возможно, что обе стороны были вдохновлены какой-то неизвестной сторонней реализацией, которая использовала все эти константы. Увы, нам не удалось найти никаких доказательств существования такого модуля. Мы должны сказать, что вероятность этого сценария довольно мала, особенно с учетом странно выглядящей строки Unicode.
Заключительное сравнение
Смысл всего этого довольно прост:
- Один APT обнаружил уязвимость и разработал для нее эксплойт.
- Другой APT захватил эксплоит и воспроизвел для себя.
Хотя оба они заслуживают полной признательности за эти замечательные достижения, мы все же хотим выяснить, кто у кого копировал. Пора сравнить эксплойты.
Кто был первоначальным разработчиком?
Странно выглядящая строка Unicode
По мнению западного исследователя, строка Unicode, используемая как для имени драйвера принтера, так и для имени печатного документа, выглядит чужеродной. И действительно, мы можем с уверенностью сказать, что строка «屁 썟» не выглядит очевидным выбором для носителей английского языка.
Поэтому мы проконсультировались с коллегами по всему миру, которые свободно говорят на китайском, корейском и японском языках, и спросили их мнение об этих двух символах. В единодушном ответе, который мы получили, было заявлено, что не существует языка, на котором эти символы имели бы смысл. В каждом языке только один символ имеет значение и в любом случае не имеет смысла как часть двухсимвольной фразы. Мы также проверили значение символов, созданных путем инвертирования порядка исходных байтов, и результат был таким же.
Так что, вероятно, это не китайская фраза, использованная первоначальными разработчиками эксплойта, но что это такое?
Наша основная гипотеза основана на мнениях разработчиков. Помимо имен файлов DLL и импортированных функций, очень редко можно найти какую-либо строку в образцах Equation Group. Даже имя созданного окна - это всего лишь "h", а не совсем длинная строка, которая могла бы использоваться правилами YARA для «подписи» двоичного файла. Столкнувшись с необходимостью использовать строку Unicode, которая наверняка длиннее одной строки символов ASCII, мы считаем, что разработчики решили использовать шаблон, который соответствует их потребностям:
- Unicode-достаточный для Windows API.
- Не настоящая строка, которую могли бы отследить.
Если мы внимательно посмотрим на выбранную строку Unicode, мы увидим, что на самом деле она имеет больше смысла как фрагмент ассемблера x64:
41 5C pop r12
5F pop rdi
C3 retn
Фактически, эта последовательность байтов является очень популярным фрагментом ассемблера, который встречается почти 150 раз только в ntdll.dll. Выбор такой популярной последовательности для "строки Unicode" позволяет достичь всех заявленных целей.
Наконец, строка также может быть сгенерирована случайным образом и вообще не имеет никакого смысла.
Название окна - «h»
Как мы только что упомянули в предыдущем разделе, имя окна графического интерфейса пользователя, используемое в обоих эксплойтах, - "h". То, что может показаться случайно выбранной короткой строкой, на самом деле имеет за собой определенную историю. Поскольку самая ранняя версия PrivLib, которую нам удалось найти, датируется 2008 годом, все проанализированные нами эксплойты Equation Group использовали одну и ту же строку, когда требовалось имя окна. И эта строка всегда была "h".
Фактически, все 3 эксплойта, включенные в Houston Disk, использовали одну и ту же глобальную строку при создании своего окна:
Это небольшое свидетельство того, что первоначальными авторами эксплойтов действительно могла быть Equation Group. Однако, поскольку этот артефакт также мог быть просто совпадением, теперь мы рассмотрим дополнительные аспекты эксплойтов.
Quirks in Jian
Поддержка Windows 2000
Внимательное изучение уязвимой функции показывает нам, что Windows 2000 никогда не была уязвимой, как можно увидеть ниже:
Несмотря на то, что Windows 2000 не является уязвимой, код UMPD в Jian имеет особые случаи для Windows 2000, а Windows 2000 является частью перечисления версии ОС.
Интересная проблема заключается в том, что согласно конфигурациям эксплойтов Equation Group, EpMe не поддерживает Windows 2000. Минимальная поддерживаемая версия - Windows XP, которая идеально сочетается с уязвимыми версиями Windows.
Тот факт, что Equation Group построил надлежащие фреймворки, означает, что модуль UMPD совместно использовался между EpMe и EpMo. Различия между эксплойтами основаны на логике, специфичной для эксплойтов, которая была реализована внутри виртуальных обработчиков, которые вызываются универсальным модулем UMPD. Поскольку EpMo поддерживает Windows 2000, то же самое делает и модуль UMPD, что объясняет, почему кажется, что EpMe поддерживает эту версию Windows.
Если на мгновение предположить, что APT31 был первоначальным разработчиком эксплойта для CVE-2017-0005, зачем им вообще пытаться добавить поддержку Windows 2000? Windows 2000 никогда не была уязвимой. Чтобы быть ясным, у нас нет никаких указаний на то, что у участников была своя собственная версия эксплойта EpMo или чего-либо подобного, то есть у нас нет никаких указаний на то, что им когда-либо была нужна такая поддержка Windows 2000 для любого другого инструмента/эксплойта.
Гораздо более вероятный сценарий - APT31 скопировал эксплойт из Equation Group. Вполне вероятно, что разработчики угроз, вероятно, не до конца понимали ограничения эксплойта и поэтому оставили код, специфичный для Windows 2000, нетронутым. Старая реликвия, унаследованная от эксплойта EpMo, о котором APT31 даже не подозревал и не заботился.
Ротация значения enum
По какой-то неизвестной причине Jian содержит определения системных вызовов для 32-битного эксплойта, помимо тех, которые необходимы для 64-битного эксплойта. Хотя они не используются на практике, поскольку образец является 64-битным, они все же дают нам представление о том, как бы выглядел их 32-битный эксплойт.
Мы видим, что 32-битная логика Jian для каждого идентификатора системного вызова снова совпадает с логикой Equation Group, вплоть до уровня настройки некоторых идентификаторов на основе мажорного номера пакета обновления.
Проблема в том, что если мы проверим фактические номера системных вызовов для Windows XP Service Pack 0 и Service Pack 1, мы увидим, что условие для установки значения SP_delta некорректно. Это было правильно для эксплойта Equation Group, но неверно здесь, поскольку APT31 изменил значение wSpMajor_refined во время инициализации эксплойта.
Это обновленное значения еще более странно, поскольку в эксплойтах Equation Group о нем вообще не упоминается:
Вы можете спросить: "Зачем кому-то выполнять указанную выше ротацию значений?" Ответ на самом деле довольно прост. Из нашего прошлого анализа нескольких эксплойтов, приписываемых китайским аффилированным лицам, мы увидели, что у разработчиков есть привычка использовать значение 0 в качестве маркера "незаконного значения". Это хорошо видно, поскольку все значения пакета обновления выше 6 отображаются обратно в значение 0, которое отмечает их как "недопустимые". То же самое было и с Enum, которая была полностью увеличена на 1, заставляя Windows NT использовать значение 1 вместо 0 и зарезервировав священное значение 0 для обозначения состояния ошибки.
И все же на этот раз разработчики использовали только частичную ротацию значения пакета обновления, что привело к конфликту с допустимым значением пакета обновления 0, которое по какой-то причине они не переназначили на "1". Это означает, что 0 одновременно является недопустимым значением, которое не должно поддерживаться, и допустимым значением, которое имеет решающее значение для настройки правильных номеров системных вызовов.
Правильная настройка, вероятно, заключалась в том, чтобы увеличить все значения на 1, сопоставить недопустимые значения с 0 и настроить проверку системных вызовов на wSpMajor_refined! = 1.
И снова мы видим странную закономерность. Даже при условии, что китайские эксплойты должны зарезервировать значение 0 для недопустимых значений, код все равно выглядит странным. Разработчик, пишущий этот эксплойт с нуля, вероятно, просто увеличил бы значение wSpMajor_refined на 1, помня, что в будущих проверках Service Pack 0 будет отмечен значением 1. Вместо этого, как бы для того, чтобы не сломать существующий фрагмент кода, инициализация системного вызова по-прежнему проверяет наличие 0, и это значение одновременно и действительное, и недопустимое.
Более вероятное объяснение состоит в том, что исходный код был версией Equation Group, и что разработчики, связанные с китайскими атакующими группами, боялись взломать его, таким образом, сделав только половину в изменении значений. Этот страх взлома кода также отражается на их плохом понимании всего эксплойта.
Строка отладки в функции триггера
Jian содержит отладочную строку "int the overflow !!!" который можно найти в DrvBitBlt() UMPD - функции обратного вызова, ответственной за срабатывание уязвимости.
Как мы уже установили, эксплуатируемая уязвимость не является уязвимостью "переполнения". Хотя строка может намекать либо на "переполнение буфера", либо на "целочисленное переполнение", ни один из них не имеет никакого отношения к проблеме дизайна обратного вызова пользовательского режима, которая фактически использовалась.
Хотя это может быть всего лишь проблема языкового барьера, это еще один возможный признак того, что злоумышленники, стоящие за Jian, не правильно поняли истинную природу эксплуатируемой уязвимости.
Заключение
Вместе с дополнительными артефактами, которые соответствуют артефактам Equation Group, общим для всех эксплойтов даже еще в 2008 году, мы можем с уверенностью заключить следующее:
- Эксплойт EpMe от Equation Group, существующий по крайней мере с 2013 года, является исходным эксплойтом для уязвимости, позже обозначенной как CVE-2017-0005.
- Примерно в 2014 году APT31 удалось захватить как 32-битные, так и 64-битные образцы эксплойта EpMe Equation Group.
- Они скопировали их, чтобы построить Jian, и использовали эту новую версию эксплойта вместе со своим уникальным многоступенчатым упаковщиком.
- Jian был пойман IRT Lockheed Martin и сообщил в Microsoft, которая исправила уязвимость в марте 2017 года и Нарекла ее как CVE-2017-0005.
Тайм-Лайн
Ниже приведена временная шкала событий, связанных с обеими версиями эксплойтов того, что начиналось как EpMe (Equation Group) и в конечном итоге было наречено Microsoft как CVE-2017-0005 (APT31).
Более подробно:
- 2008/2009 - инструменты эксплойтов Early Equation Group: PrivLib/Houston Disk.
- 2013 - эксплойты DanderSpritz NtElevation: ElEi, ErNi, EpMo, EpMe.
- 27 октября 2014 г. - ранняя временная метка из встроенного PE - клонированного EpMe.
- 6 мая 2015 г. - несколько индикаторов того, что полный инструмент APT31 был собран в 2015 году.
- 13 августа 2016 г. - первая публикация Shadow Brokers.
- 8 января 2017 г. - Shadow Brokers допустили утечку структуры каталогов своих файлов, что явно указывает на владение эксплойтами DanderSpritz и Eternal*.
- 14 февраля 2017 г. - вторник исправлений отменен и объединен с мартовскими исправлениями.
- 14 марта 2017 г. - вторник исправлений - исправлены уязвимости CVE-2017-0005 и 1-й раунд критических эксплойтов Equation Group, включенных в подлежащую публикации утечку SB "Lost in Translation".
- 27 марта 2017 г. - Microsoft публикует блог о CVE-2017-0005, о котором сообщил Lockheed Martin, и приписывает его китайскому APT (Zirconium/APT31).
- 14 апреля 2017 г. - опубликована утечка Lost in Translation.
- 9 мая 2017 г. - вторник исправлений: второй раунд исправлений Equation Group включает тихое исправление для эксплойта EpMo Equation Group.
Резюме
Мы начали с анализа "Jian", китайского эксплойта (APT31/Zirconium) для CVE-2017-0005, о котором сообщила группа реагирования на компьютерные инциденты Lockheed Martin. К нашему удивлению, мы обнаружили, что этот эксплойт APT31 на самом деле является реконструированной версией эксплойта Equation Group под названием "EpMe". Это означает, что эксплойт Equation Group в конечном итоге был использован группой, связанной с Китаем, вероятно, против американских целей. Это не первый задокументированный случай китайского APT, использующего 0-Day.
Во-первых, APT3 использовал собственную версию EternalSynergy (называемую UPSynergy) после приобретения эксплойта EternalRomance Equation Group. Однако в случае с UPSynergy наша группа исследователей безопасности, а также Symantec пришли к единому мнению, что китайский эксплойт был воссоздан из перехваченного сетевого трафика.
Случай с EpMe/Jian отличается, поскольку мы ясно показали, что Jian был создан из фактических 32-битных и 64-битных версий эксплойта Equation Group. Это означает, что в этом сценарии китайский APT сам приобрел образцы эксплойтов во всех поддерживаемых ими версиях. Датировав образцы APT31 за 3 года до утечки Lost in Translation от Shadow Broker, мы полагаем, что эти образцы эксплойтов Equation Group могли быть получены китайским APT одним из следующих способов:
При обзоре эксплойтов NtElevation, используемых в постэксплуатационном фрейворке DanderSpritz Equation Group, мы обнаружили 4 эксплойта Windows LPE. Первые два эксплойта NtElevation были уязвимостями шрифтов, которые ранее обсуждались как часть Houston disk (более ранний образец, приписываемый Equation Group). Кроме того, EpMe (CVE-2017-0005) был упомянут и исправлен, когда Jian был захвачен, даже если на тот момент его истинное происхождение еще не было известно.
Наконец, хотя в мае 2017 года Microsoft действительно исправила EpMo, мы не смогли отследить CVE-ID, присвоенный исправленной уязвимости. Мало того, насколько нам известно, наша публикация является первой, в которой даже упоминается о существовании этого эксплойта Equation Group, хотя он был общедоступным на GitHub в течение последних 4 лет.
Это наши новые дополнения к карте атрибутики:
- EpMe (CVE-2017-0005) - эксплойт Equation Group, который был клонирован APT31.
- EpMo - дополнительный эксплойт Equation Group, который ранее никогда не обсуждался.
- Jian - клонированная версия APT31 EpMe, которая была обнаружена IRT Lockheed Martin.
- CVE-2019-0803 - из нескольких источников приписывается "хакеру", спонсируемому государством из Китая. Мы показали, что он использует тот же загрузчик эксплойтов (и API инструмента), что и Jian в APT31.
Источник: https://research.checkpoint.com/2021/the-story-of-jian/
Автор перевода: yashechka
Переведено специально для https://xss.pro