Введение в реестр Windows
При проведении исследования уязвимости важно убедиться, что все связанные с эксплуатацией векторы атак исследованы. Один из способов атаки состоит в использовании реестра Windows . Для злоумышленника в реестре Windows хранятся критически важные данные, на которые приложения могут полагаться во время работы. Не только приложения полагаются на эти данные, но также и сервисы, и даже сама ОС Windows полагается на информацию внутри реестра для правильного функционирования.
В этой статье содержится подробная информация о реестре Windows и о том, как неправильное назначение разрешений для разделов реестра может привести к уязвимостям в приложениях или службах , которые используют эту функцию.
Реестр Windows Реестр
Реестр Windows - это база данных, в которой хранятся данные конфигурации для ОС Windows, а также различные приложения и сервисы, которые используют его функции. А также при наличии соответствующих разрешений, эти приложения и сервисы могут читать, записывать и изменять реестр.
С точки зрения злоумышленника, реестр Windows является привлекательной целью.
Это связано с тем, что существует множество различных случаев использования, по которым приложение или сервис могут использовать эту расширенную функциональность. Случаи использования, рекомендованные корпорацией Майкрософт, предназначены для функциональности конфигурации и времени выполнения.
При работе с реестром Windows необходимо назначать соответствующие разрешения каждому созданному ключу. Причина этого заключается в том, чтобы предотвратить несанкционированный доступ к потенциально важным данным в данном разделе реестра. Следующая тема, представляющая интерес, - это понимание того, как поставить разрешения на ключевые данные реестра.
Разрешения реестра Windows
Разрешения являются основным компонентом операционных систем и реализуются многими способами.
Когда дело доходит до операционной системы Windows, разрешения назначаются с помощью списков контроля доступа (ACL). ACL состоят из записей контроля доступа (ACE), которые содержат две отдельные структуры разрешений.
Первый - это Список контроля доступа по усмотрению (DACL), а второй - Список контроля доступа по системе (SACL). DACL - это то, что нас больше всего интересует, поскольку он определяет, кто может получить доступ к указанному ресурсу для изменения, записи, чтения или выполнения соответственно. SACL, с другой стороны, предназначен для регистрации в журнале событий безопасности.
Чтобы просмотреть списки DACL данного ресурса, мы можем использовать инструмент
В этом столбце представлена информация о том, для каких пользователей или групп существуют разрешения, какие бывают возможности записи (
Рисунок 1: AccessEnum реестра Пример сканирования
После выбора этой опции появится новое всплывающее окно, предлагающее возможность выбрать любой доступный раздел реестра. Для этого примера был выбран раздел реестра
Рисунок 2: Результаты сканирования реестра AcccessEnum
Когда дело доходит до проверки разрешений раздела реестра, важно отметить использование определенных разрешений. Эти разные разрешения связаны с различными функциями, предоставляемыми через реестр Windows. Одним из таких примеров является разрешение
Полный список разрешений, включая определенные, приведен в списке ниже:
Мы рассмотрели общую информацию и разрешения, касающиеся реестра Windows. В следующем разделе подробно описана уязвимость локального повышения привилегий (LPE), влияющая на службу системного уровня из-за неправильного использования разрешений раздела реестра Windows.
Злоупотребление записями разделов реестра с реальной уязвимостью
Введение в "Waves Maxx Audio Registry Key" злоупотребление LPE для системы
Waves Maxx Audio (Waves) - это программный пакет, который предлагает расширенные настройки для потребительских и профессиональных продуктов. Это программное обеспечение предустановлено на нескольких разных ноутбуках Dell. Waves устанавливает службу с именем
Эта служба устанавливает дескриптор раздела реестра с именем
Обнаружение с помощью динамического анализа
Эта уязвимость была обнаружена во время анализа времени выполнения с помощью инструмента
Рисунок 3: Фильтры Procmon
Эти фильтры предоставляют полезную информацию о любой потенциальной записи раздела реестра, где значение данных содержит ссылки на DLL или исполняемый файл двоичного приложения. Операция
Увидев это, первое, что мы проверили, - это разрешения, связанные с файлом
Рисунок 4: Результаты AccessEnum сканирования для MaxxAudioIntelKabylake64.dll
Просмотр результатов разрешений для данного ресурса показывает, что только
Следующее, что мы проверили, - это раздел реестра, на который ссылаются до выполнения этой загрузки изображения операции. Это связано с тем, что вскоре после выполнения
Рисунок 5: Regedit MaxxAudio \ Общий вид ключа
Далее, щелкните правой кнопкой мыши на ключе с именем
Теперь, когда мы убедились, что группе
Анализ причин
Необходим дальнейший анализ, чтобы глубже понять, почему существует эта уязвимость и как ее можно использовать. Для выполнения этой задачи будут использованы два основных инструмента. Этими инструментами являются
Первая задача, которую мы выполнили, - это определение двоичного файла службы, отвечающего за функциональность, связанную со службой Waves. Мы использовали инструмент командной строки
Рисунок 6: Результаты службы BINARY_PATH_NAME службы SC
Из изображения выше видно, что
Инструмент
Рисунок 7: Внешний вид Gflags
Далее выберите вкладку
Полный путь, где
Причина, по которой мы устанавливаем TTD файл в качестве опции отладчика внутри
После настройки этих параметров в
Как упоминалось ранее в предыдущих разделах, эта уязвимость связана с загрузкой DLL. Теперь эта атака довольно расплывчата и может быть осуществлена разными способами. Однако главное, что DLL загружается в область памяти процессов. Вооружившись этими знаниями, мы можем сделать вывод, что используются
После установки этой команды и запуска отладчика, мы ищем конкретное место, где вызовы, которые содержат значение аргумента, равное нашей первой DLL, на которую ссылается имя записи
Как мы можем видеть из вывода, когда мы входим в
Согласно приведенному выше фрагменту кода ключ реестра и его путь должны передаваться через аргумент
После создания дескриптора мы вводим переименованную функцию
Теперь, согласно документации Microsoft для функции
Эта строка, разделенная точкой с запятой, которая была перечислена из значения данных записи ключа
Функция
После входа в последнюю функцию, где существует уязвимый вызов
После того, как ссылочная ячейка памяти обновляется с помощью вызова
Наконец, мы установим точку "breakpoint " со смещением адреса
Изучив вышеприведенный вывод, мы можем убедиться в правильности нашего анализа. Основными моментами, затронутыми на этом этапе анализа, были создание раздела реестра, перечисление значений данных
Эксплуатация
Мы воспользуемся этой уязвимостью, заменив первую DLL-библиотеку, указанную перед первым токеном; с абсолютным путем к нашей вредоносной DLL. Внутри нашей вредоносной DLL мы поместим нашу полезную нагрузку в функцию
Теперь, когда мы рассмотрели устройство атаки, следующая вещь, которую мы рассмотрим, - это фактическое использование этой уязвимости. Первым делом мы создали простую DLL, в которой функция
Этот код проверки концепции (PoC) используется для демонстрации возможности получения сеанса интерактивной командной строки на системном уровне. Код, ответственный за это, можно увидеть в фрагменте кода ниже:
Мы использовали Python для автоматизации перезаписи данных в имени записи в разделе
Этот сценарий PoC Python принимает один аргумент. Этот аргумент является абсолютным путем вредоносной DLL. Этот скрипт принимает аргумент и добавляет его к переменной
После запуска этого сценария PoC и ручного перезапуска службы Waves мы используем ncat, чтобы установить соединение с
Заключение
В VerSprite мы заметили, что тенденция неправильного назначения разрешений для критических ресурсов довольно распространена. Влияние неправильного назначения разрешений варьируется от утечки информации до выполнения кода. Чтобы противостоять этому, при обработке создания и / или использования разделов реестра и сопутствующих записей значений важно применять соответствующие разрешения. Применив соответствующие разрешения, атака, представленная в этом блоге, будет предотвращена.
Если вы заинтересованы в дальнейшем чтении уязвимостей в программном обеспечении Windows, ниже приведен список недавних уязвимостей и анализ эксплуатации:
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://versprite.com/blog/security-research/windows-registry/
При проведении исследования уязвимости важно убедиться, что все связанные с эксплуатацией векторы атак исследованы. Один из способов атаки состоит в использовании реестра Windows . Для злоумышленника в реестре Windows хранятся критически важные данные, на которые приложения могут полагаться во время работы. Не только приложения полагаются на эти данные, но также и сервисы, и даже сама ОС Windows полагается на информацию внутри реестра для правильного функционирования.
В этой статье содержится подробная информация о реестре Windows и о том, как неправильное назначение разрешений для разделов реестра может привести к уязвимостям в приложениях или службах , которые используют эту функцию.
Реестр Windows Реестр
Реестр Windows - это база данных, в которой хранятся данные конфигурации для ОС Windows, а также различные приложения и сервисы, которые используют его функции. А также при наличии соответствующих разрешений, эти приложения и сервисы могут читать, записывать и изменять реестр.
С точки зрения злоумышленника, реестр Windows является привлекательной целью.
Это связано с тем, что существует множество различных случаев использования, по которым приложение или сервис могут использовать эту расширенную функциональность. Случаи использования, рекомендованные корпорацией Майкрософт, предназначены для функциональности конфигурации и времени выполнения.
При работе с реестром Windows необходимо назначать соответствующие разрешения каждому созданному ключу. Причина этого заключается в том, чтобы предотвратить несанкционированный доступ к потенциально важным данным в данном разделе реестра. Следующая тема, представляющая интерес, - это понимание того, как поставить разрешения на ключевые данные реестра.
Разрешения реестра Windows
Разрешения являются основным компонентом операционных систем и реализуются многими способами.
Когда дело доходит до операционной системы Windows, разрешения назначаются с помощью списков контроля доступа (ACL). ACL состоят из записей контроля доступа (ACE), которые содержат две отдельные структуры разрешений.
Первый - это Список контроля доступа по усмотрению (DACL), а второй - Список контроля доступа по системе (SACL). DACL - это то, что нас больше всего интересует, поскольку он определяет, кто может получить доступ к указанному ресурсу для изменения, записи, чтения или выполнения соответственно. SACL, с другой стороны, предназначен для регистрации в журнале событий безопасности.
Чтобы просмотреть списки DACL данного ресурса, мы можем использовать инструмент
AccessEnum из SysInternals Suite. AccessEnum - это универсальный инструмент, который предлагает функциональные возможности для быстрого перечисления разрешений ресурсов. Помимо простого перечисления файлов и папок в операционной системе Windows, он также может перечислять разрешения ключей в реестре Windows. При использовании AccessEnum для перечисления разрешений, столбец Write содержит наиболее ценную информацию.В этом столбце представлена информация о том, для каких пользователей или групп существуют разрешения, какие бывают возможности записи (
write). AccessEnum предлагает возможность перемещаться по реестру по умолчанию с возможностью, доступной для конечных пользователей. Это выполняется с помощью параметра Registry, предоставляемого AccessEnum , и рисунок 1 отображает этот параметр.
Рисунок 1: AccessEnum реестра Пример сканирования
После выбора этой опции появится новое всплывающее окно, предлагающее возможность выбрать любой доступный раздел реестра. Для этого примера был выбран раздел реестра
HKEY_LOCAL_MACHINE. Сканирование перечисляет каждый подраздел в этом первичном ключе и отображает разрешения соответственно для каждого подраздела. На рисунке 2 рассмотрен пример перечисления разрешений.
Рисунок 2: Результаты сканирования реестра AcccessEnum
Когда дело доходит до проверки разрешений раздела реестра, важно отметить использование определенных разрешений. Эти разные разрешения связаны с различными функциями, предоставляемыми через реестр Windows. Одним из таких примеров является разрешение
Set Value. Оно позволяет изменять значения в разделе реестра.Полный список разрешений, включая определенные, приведен в списке ниже:
- Full Control
- Query Value
- Set Value
- Createsubkey
- Enumerate Subkeys
- Notify
- Create Link
- Delete
- Write DAC
- Write Owner
- Read Control
Мы рассмотрели общую информацию и разрешения, касающиеся реестра Windows. В следующем разделе подробно описана уязвимость локального повышения привилегий (LPE), влияющая на службу системного уровня из-за неправильного использования разрешений раздела реестра Windows.
Злоупотребление записями разделов реестра с реальной уязвимостью
Введение в "Waves Maxx Audio Registry Key" злоупотребление LPE для системы
Waves Maxx Audio (Waves) - это программный пакет, который предлагает расширенные настройки для потребительских и профессиональных продуктов. Это программное обеспечение предустановлено на нескольких разных ноутбуках Dell. Waves устанавливает службу с именем
WavesSysSvc, которая настроена на автоматический запуск и запускается как LocalSystem во время выполнения.Эта служба устанавливает дескриптор раздела реестра с именем
General и запрашивает запись со значением имени ExternalModule, которое содержит строку, разделенную точкой с запятой, в качестве значения данных. Эта строка содержит имена динамически подключаемой библиотеки (DLL), которые загружаются в память процесса при его запуске. Этот раздел реестра имеет неправильные разрешения, которые позволяют любому пользователю (User) изменять записи. Злоумышленник может злоупотребить назначенными разрешениями, чтобы провести атаку с боковой загрузкой DLL и добиться повышения локальных привилегий.Обнаружение с помощью динамического анализа
Эта уязвимость была обнаружена во время анализа времени выполнения с помощью инструмента
Procmon из SysInternals Suite. Procmon - это универсальный инструмент, который используется для просмотра различных типов операций, выполняемых приложением. Конкретными операциями, которые привели к этому открытию, были Load Image и RegQueryValue. На рисунке 3 можно увидеть этот конкретный фильтр в Procmon.
Рисунок 3: Фильтры Procmon
Эти фильтры предоставляют полезную информацию о любой потенциальной записи раздела реестра, где значение данных содержит ссылки на DLL или исполняемый файл двоичного приложения. Операция
RegQueryValue относится к функции APIWindows RegQueryValue соответственно и возвращает результаты определенных значений данных в записи ключа реестра в Detail столбце. Вторая операция, Load Image, используется для захвата функциональности, связанной с загрузкой библиотеки или изображения в область памяти процесса. При анализе вывода результирующего фильтра, мы находим что DLL указанное в Detail столбце RegQueryValue операции также присутствует в Load Image пути (Path) столбца. Это видно ниже, из Procmon вывода CSV.
Увидев это, первое, что мы проверили, - это разрешения, связанные с файлом
MaxxAudioIntelKabylake64.dll. Учитывая, что этот файл находится в C:\Windows\System32\, пользователь может не иметь надлежащих разрешений для злоупотребления этим локальным ресурсом. Проверка разрешений, связанных с этим ресурсом, может быть выполнена с помощью инструмента AccessEnum из SysInternals Suite. Для этого мы скопировали абсолютный путь, представленный в Path --> Load Image, операции в разделе поиска AccessEnum,нажали затем кнопку Scan. Результаты разрешений, связанных с этим файлом, можно просмотреть в окне нижней панели AccessEnum.
Рисунок 4: Результаты AccessEnum сканирования для MaxxAudioIntelKabylake64.dll
Просмотр результатов разрешений для данного ресурса показывает, что только
NT AUTHORITY \ SYSTEM имеет разрешения на запись в этот файл. Эти разрешения не подходят, так как обычные пользователи не могут изменять этот файл.Следующее, что мы проверили, - это раздел реестра, на который ссылаются до выполнения этой загрузки изображения операции. Это связано с тем, что вскоре после выполнения
RegQueryValue операции эта DLL-библиотека загружается в область WavesSysSvc64.exe памяти процесса. Мы использовали инструмент Regedit от Microsoft для просмотра разрешений, связанных с данным ключом реестра. Используя Regedit, мы перешли к тому же пути к ключу реестра, который был записан с помощьюProcmon.
Рисунок 5: Regedit MaxxAudio \ Общий вид ключа
Далее, щелкните правой кнопкой мыши на ключе с именем
General и выберите опцию под названием Permissions. После выбора этого параметра найдите группу Users и просмотрите соответствующие разрешения. Учитывая, что группа Users имеет полный контроль над этим общим разделом реестра, можно выполнять манипуляции с записями в этом ключе.Теперь, когда мы убедились, что группе
Users назначено Full Control permission для раздела реестра с именем General, следующий шаг - проверка этой информации путем выполнения статического и динамического анализа двоичных файлов службы Waves в следующем разделе.Анализ причин
Необходим дальнейший анализ, чтобы глубже понять, почему существует эта уязвимость и как ее можно использовать. Для выполнения этой задачи будут использованы два основных инструмента. Этими инструментами являются
IDA Pro от Hex-Rays и WinDbg Preview от Microsoft. Теперь, имея дело с анализом IDA Pro, я рассмотрю только основные разделы, касающиеся уязвимости. Для предварительного просмотра WinDbg мы использовали независимую двоичную версию Time Travel Debugging (TTD). TTD используется из-за его способности просматривать трассировки, чтобы получить представление о памяти и выполняемых инструкциях и значениях аргументов, передаваемых функциям во время выполнения.Первая задача, которую мы выполнили, - это определение двоичного файла службы, отвечающего за функциональность, связанную со службой Waves. Мы использовали инструмент командной строки
sc, который используется для сбора информации и выдачи команд сервисам. Информация, которую мы хотим получить из выходных данных sc инструмента, - это BINARY_PATH_NAME поле для службы Waves. Мы использовали qc флаг, который запрашивает конкретный сервис для получения информации о конфигурации.
Рисунок 6: Результаты службы BINARY_PATH_NAME службы SC
Из изображения выше видно, что
BINARY_PATH_NAME содержит абсолютный путь к двоичному файлу службы Waves. Этот двоичный файл - то, что выполняется, как только эта служба запущена. Получив эту информацию, мы использовали WinDbg Time Travel Debugger, чтобы записать функциональность во время выполнения. Для выполнения этого действия мы использовали инструмент GFlags от Microsoft. GFlags можно использовать как в командной строке, так и в режиме графического интерфейса пользователя (GUI) с одинаковыми функциями. Этот инструмент будет использоваться для установки инструмента WinDbg TTD в качестве отладчика опции для создания файла трассировки после запуска этой службы.Инструмент
GFlags входит в состав WinDbg и может быть загружен здесь. После того, как все правильно установлено, запустите Gflags.exe, и должно появиться окно как на рисунке 7.
Рисунок 7: Внешний вид Gflags
Далее выберите вкладку
Image File. В этом виде две точки будут изменены. Первый - это Image File. Для этого раздела введите имя двоичной службы(service binary) файла WavesSysSvc64.exe и нажмите клавишу Tab. После этого все остальное должно стать доступным для модификации. Второй вариант для изменения - это отладчик параметра. Для этого параметра передайте полный путь к двоичному файлу TTD для отладки вместе с аргументами, приведенными во фрагменте ниже:
Полный путь, где
TTD, расположен может отличаться, поэтому обязательно измените его на текущий путь для своей среды. Опция -maxfile предназначена для установки максимального размера файла трассировки - 2 ГБ. Опция -out указывает местоположение для хранения файла трассировки, и, наконец, используется команда-launch. Причина, по которой у команды -launch нет следующего двоичного файла для запуска, заключается в том, что после установки этого значения GFlags автоматически назначает двоичный файл службы в качестве последнего передаваемого аргумента. Поскольку двоичный файл службы является последним передаваемым аргументом, обязательно добавьте завершающий пробел после команды -launch. Наконец, выберите применить, и эти новые настройки будут установлены.Причина, по которой мы устанавливаем TTD файл в качестве опции отладчика внутри
Gflags, заключается в том, что WinDbg Preview TTD не поддерживает активную трассировку процессов Session 0 через использование по умолчанию. Используя GFlags, это ограничение можно обойти, потому что GFlags запускает TTD в том же сеансе, что и двоичный файл службы Waves. Это позволяет выполнять трассировку.После настройки этих параметров в
GFlags и убедившись, что все работает правильно, мы можем приступить. Для выполнения этой задачи будет использован инструмент Procexp из SysInternals Suite. Procexp - это инструмент, который используется для просмотра подробной информации о запущенных процессах. Когда Procexp открыт, найдите TTD.exe и завершите процесс. После завершения процесса TTD трассировка будет завершена и будет соответствующим образом записана. Она может быть предоставлена для предварительного просмотра и анализа WinDbg.Как упоминалось ранее в предыдущих разделах, эта уязвимость связана с загрузкой DLL. Теперь эта атака довольно расплывчата и может быть осуществлена разными способами. Однако главное, что DLL загружается в область памяти процессов. Вооружившись этими знаниями, мы можем сделать вывод, что используются
LoadLibrary, функции предоставляемые через библиотеку Kernel32. Эти LoadLibrary функции можно вызывать много раз, поэтому, используя простую однострочную команду WinDbg, мы можем перебирать все вызовы LoadLibraryA, выводить содержимое аргумента, передаваемого через регистр RCX, и выгружать стек вызовов. Эту команду можно увидеть ниже:
После установки этой команды и запуска отладчика, мы ищем конкретное место, где вызовы, которые содержат значение аргумента, равное нашей первой DLL, на которую ссылается имя записи
ExternalModule и ключ реестра General . При просмотре этого вывода первая DLL-библиотека, на которую ссылаются, найдена, и вывод можно увидеть ниже:
Как мы можем видеть из вывода, когда мы входим в
LoadLibraryA функцию, переданный аргумент содержит наше конкретное имя DLL. После этого был сгенерирован стек вызовов. После информации о стеке вызовов присутствует ModLoad . Modload сообщает, что DLL-библиотека, на которую ссылается DLL, была загружена в область памяти процесса. Итак, учитывая эту информацию, мы можем сделать вывод, что инструкция перед смещением адреса в MaxxAudioAPOShell64! WavesFX_Preset_SetSoundMode + 0x54895 фактически является LoadLibraryA функцией. Следующим шагом будет выяснить, как это значение получается из ExternalModule записи реестра. На этом этапе мы будем использовать инструмент IDA Pro и разберем MaxxAudioAPOShell64.dll. Сначала мы искали использование функции RegQueryValue, так как эта функция используется для возврата значения данных, связанного с конкретным именем записи в разделе реестра. Однако для успешной работы этой функции сначала необходимо создать дескриптор для раздела реестра General. Это выполняется с помощью функции RegCreateKey. Итак, после небольшого количества перекрестных ссылок и дополнительной отладки с помощью WinDbg была найдена конкретная функция RegCreateKey. Эту информацию можно увидеть во фрагменте ниже:
Согласно приведенному выше фрагменту кода ключ реестра и его путь должны передаваться через аргумент
lpSubKey (RDX) в RegCreateKeyExA функцию. Чтобы убедиться в этом, мы установили точку останова со смещением адреса 0x2C67B внутри MaxxAudioAPOSHell64.dll, используя WinDbg, и отобразили содержимое RDX. Содержимое вместе с выводом WinDbg можно увидеть в следующем фрагменте:
После создания дескриптора мы вводим переименованную функцию
AAA_regqueryvalue, в которой перечисляются значения данных из указанной выше записи реестра ExternalModule . Итак, если мы перейдем к этой функции, мы найдем использование функцииRegQueryValueExA. Рассматривая этот вызов, мы замечаем, что ExternalModule передается имя записи раздела реестра. Это можно увидеть в следующем фрагменте кода:
Теперь, согласно документации Microsoft для функции
RegQueryValueExA, если мы хотим увидеть значения данных, которые восстанавливаются из записи с именем ExternalModule, нам нужно будет отобразить содержимое [rsp + 218h + lpData] после вызова этой функции. Следующий фрагмент WinDbg ниже показывает результат, который мы ожидали увидеть.
Эта строка, разделенная точкой с запятой, которая была перечислена из значения данных записи ключа
ExternalModule, затем позже передается в качестве аргумента в вызов функции _mbschr function. Код, ответственный за это, можно увидеть в фрагменте IDA Pro ниже:
Функция
_mbschr вернет указатель, смещенный к первому вхождению указанного токена. В нашем случае возвращаемый указатель указывает на ; токен, на который ссылается значение данных. Следующий код после этого вызова функции, по сути, копирует первую строку, восстановленную до нашего токена ; и передает его нашей последней функции, которая содержит вызов LoadLibraryA через RDX регистр.После входа в последнюю функцию, где существует уязвимый вызов
LoadLibraryA, незадолго до этого также вызывается функция strcpy_s. Эта функция strcpy_s копирует ссылку на наше первое имя DLL в выделенную память, на которую в настоящий момент указывает RCX. В начале этой функции ссылка на RCX сохраняется в регистре RBX, и когда вызывается эта функция strcpy_s; все ссылки обновляются "первым именем DLL" из значения данных ExternalModule.После того, как ссылочная ячейка памяти обновляется с помощью вызова
strcpy_s, вызывается финальная функция LoadLibraryA, в которую загружается DLL. Код, ответственный за это, можно увидеть ниже во фрагменте кода IDA Pro.
Наконец, мы установим точку "breakpoint " со смещением адреса
0x5AC1F внутри DLL MaxxAudioAPOShell64.dll и выведем содержимое аргумента имени ресурса, переданного через RCX в функцию LoadLibraryA. Результаты WinDbg можно увидеть в приведенном ниже фрагменте кода:
Изучив вышеприведенный вывод, мы можем убедиться в правильности нашего анализа. Основными моментами, затронутыми на этом этапе анализа, были создание раздела реестра, перечисление значений данных
ExternalModule имени ключа раздела реестра, поиск строки токена для идентификации каждой загружаемой DLL-библиотеки и, наконец, уязвимая функция, вызывающая себя самостоятельно. Теперь, когда мы рассмотрели раздел анализа этой уязвимости, последний этап - эксплуатация!Эксплуатация
Мы воспользуемся этой уязвимостью, заменив первую DLL-библиотеку, указанную перед первым токеном; с абсолютным путем к нашей вредоносной DLL. Внутри нашей вредоносной DLL мы поместим нашу полезную нагрузку в функцию
DLLMain. Функция DLLMain по отношению к DLL уникальна, потому что всякий раз, когда DLL загружается в область памяти процесса через LoadLibrary или аналогичные функции, функция DLLMain выполняется автоматически. Учитывая, что служба Waves настроена для работы в качестве учетной записи LocalSystem, все порожденные дочерние процессы будут наследовать разрешения системы.Теперь, когда мы рассмотрели устройство атаки, следующая вещь, которую мы рассмотрим, - это фактическое использование этой уязвимости. Первым делом мы создали простую DLL, в которой функция
DLLMain вызывает другую функцию с именем bind_shell.Этот код проверки концепции (PoC) используется для демонстрации возможности получения сеанса интерактивной командной строки на системном уровне. Код, ответственный за это, можно увидеть в фрагменте кода ниже:
Мы использовали Python для автоматизации перезаписи данных в имени записи в разделе
ExternalModule реестра General. PoC на основе Python можно увидеть ниже:
Этот сценарий PoC Python принимает один аргумент. Этот аргумент является абсолютным путем вредоносной DLL. Этот скрипт принимает аргумент и добавляет его к переменной
reg_value_data, которая передается в функцию set_registry. Функция set_registry выполняет действие по изменению записи с именем ExternalModule значения данных соответственно. Этот скрипт может успешно выполняться из любой учетной записи в группе Users. Вывод ниже отображает вывод скрипта Python после его выполнения.
После запуска этого сценария PoC и ручного перезапуска службы Waves мы используем ncat, чтобы установить соединение с
localhost на порту 4444, чтобы получить оболочку уровня SYSTEM. Это можно увидеть в окне ниже:
Заключение
В VerSprite мы заметили, что тенденция неправильного назначения разрешений для критических ресурсов довольно распространена. Влияние неправильного назначения разрешений варьируется от утечки информации до выполнения кода. Чтобы противостоять этому, при обработке создания и / или использования разделов реестра и сопутствующих записей значений важно применять соответствующие разрешения. Применив соответствующие разрешения, атака, представленная в этом блоге, будет предотвращена.
Если вы заинтересованы в дальнейшем чтении уязвимостей в программном обеспечении Windows, ниже приведен список недавних уязвимостей и анализ эксплуатации:
- Waves MaxxAudio LPE
- Эксплуатация уязвимостей WCF
- Перечисление типов атак приложений на пользователя Windows
- Злоупотребление небезопасными точками Windows Communication Foundation (WCF)
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://versprite.com/blog/security-research/windows-registry/