Если ты часто имеешь дело с различными операционными системами, то вероятнее всего слышал о программных продуктах для создания виртуальной изолированной среды на твоем компьютере. В них ты можешь развернуть любую ось, накатит пару сотен полезных приложений и выполнить задуманное. Но в этот раз давай поговорим о таком продукте как VirtualBox. Это популярное кроссплатформенное программное обеспечение для виртуализации с открытым исходным кодом, разработанное корпорацией Oracle. Чуть ранее в этом же году группа ИБ специалистов обнаружила очень интересных баг в коде. Что он дает? Для начала это самый быстрый и безболезненный путь к повышению привилегий в системе. Как ты уже догадался, сегодня речь пойдет именно об этом баге. Попробуем разобраться как он устроен и успешно эксплуатируем его в виртуальной среде.
Обнаружение уязвимости
Для работы нам потребуется образ Windows 10 и среда виртуализации VirtualBox. Думаю с этим ты справишься без моей помощи. После установки и базовой настройки в системе появится очень интересная пользовательская служба с названием VirtualBox system service, она нам потребуется. Запускаем Powershell и смотрим, что она из себя представляет:
PS C:\tools> sc.exe qc VboxSDS [SC] QueryServiceConfig SUCCESS SERVICE_NAME: VboxSDS TYPE : 10 WIN32_OWN_PROCESS START_TYPE : 3 DEMAND_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : "C:\\Program Files\\Oracle\\VirtualBox\\VBoxSDS.exe" LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : VirtualBox system service DEPENDENCIES : RPCSS SERVICE_START_NAME : LocalSystemТут мы видим путь до самой службы и понимаем, что это системная папка, а также замечаем стартовое имя LocalSystem. Это говорит о том, что файл VBoxSDS.exe обладает правами системы. Сама служба создает каталог C:\\ProgramData\\VirtualBox\\для ведения журнала.
Этот каталог создается без указания явных списков ACL и наследует разрешения родительского каталога (C:\ProgramData), что позволяет пользователям создавать новые файлы/папки:
PS C:\tools> cacls.exe C:\ProgramData\VirtualBox C:\\ProgramData\\VirtualBox NT AUTHORITY\\SYSTEM:(OI)(CI)(ID)F BUILTIN\\Administrators:(OI)(CI)(ID)F CREATOR OWNER:(OI)(CI)(IO)(ID)F BUILTIN\\Users:(OI)(CI)(ID)R BUILTIN\\Users:(CI)(ID)(special access:) FILE_WRITE_DATA FILE_APPEND_DATA FILE_WRITE_EA FILE_WRITE_ATTRIBUTESПри запуске службы эта папка будет заполнена файлами журналов, они будут наследовать разрешения каталога, что не позволит пользователям с низкими привилегиями изменять/удалять их и, как следствие, ограничивать злоупотребление соединениями каталогов — популярный примитив, используемый при эксплойтах. Но здесь имеются ошибки доступа в логике службы:
PS C:\tools> ls C:\ProgramData\VirtualBox\ Directory: C:\\ProgramData\\VirtualBox Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 4/22/2024 9:44 AM 0 VBoxSDS.log -a---- 4/22/2024 9:43 AM 1924 VBoxSDS.log.1 -a---- 4/12/2024 1:49 AM 1924 VBoxSDS.log.10 -a---- 4/19/2024 5:32 PM 1924 VBoxSDS.log.2 -a---- 4/18/2024 10:41 AM 1281 VBoxSDS.log.3 -a---- 4/17/2024 11:27 PM 1924 VBoxSDS.log.4 -a---- 4/17/2024 10:20 PM 665 VBoxSDS.log.5 -a---- 4/17/2024 10:20 PM 1431 VBoxSDS.log.6 -a---- 4/15/2024 11:04 PM 1925 VBoxSDS.log.7 -a---- 4/15/2024 1:30 PM 665 VBoxSDS.log.8 -a---- 4/15/2024 1:30 PM 1431 VBoxSDS.log.9 PS C:\\tools> cacls.exe C:\\ProgramData\\VirtualBox\\VBoxSDS.log C:\\ProgramData\\VirtualBox\\VBoxSDS.log NT AUTHORITY\\SYSTEM:(ID)F BUILTIN\\Administrators:(ID)F BUILTIN\\Users:(ID)RАнализ службы во время запуска показывает интересное поведение, когда служба VboxSDS рекурсивно выполняет операцию переименования/перемещения файлов внутри каталога C:\\ProgramData\\VirtualBox. VboxSDS.log станет VboxSDS.log.1, а VboxSDS.log.1 станет VboxSDS.log.2:
Если единственный файл внутри каталога — VboxSDS.log.10, то он будет удален:
Этим можно злоупотреблять как для удаления файлов в каталоге, так и для выполнения произвольного перемещения файлов.
Чтобы очистить каталог, нам нужна возможность запустить службу от имени пользователя с низкими привилегиями, а также возможность остановить/свернуть службу, поскольку в большинстве случаев каталог будет содержать несколько файлов журналов.
Запустить службу от имени пользователя с низкими привилегиями можно через COM. Служба VboxSDSрегистрирует COM-сервер, и всякий раз, когда этот COM-класс инициируется, запускается служба:
PS C:\tools> sc.exe queryex VboxSDS SERVICE_NAME: VboxSDS TYPE : 10 WIN32_OWN_PROCESS STATE : 1 STOPPED WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 PID : 0 FLAGS : PS C:\tools> [Activator]::CreateInstance([type]::GetTypeFromCLSID("74AB5FFE-8726-4435-AA7E-876D705BCBA5")) System.__ComObject PS C:\tools> sc.exe queryex VboxSDS SERVICE_NAME: VboxSDS TYPE : 10 WIN32_OWN_PROCESS STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 PID : 11364 FLAGS : Самый простой способ, с помощью которого я обнаружил сбой службы — это запретить ей создавать файл VboxSDS.log.
Это можно сделать несколькими способами, однако я считаю, что проще всего создать каталог с именем VboxSDS.log, чтобы последующий вызов CreateFile API завершился неудачей, поскольку будет ожидаться файл.
Итак, с природой данной уязвимости мы разобрались, теперь закрываем все лишние окна и переходим к ее эксплуатации с первоначальными правами пользователя.
Эксплуатация уязвимости
Имея на руках возможность очистить каталог и запустить службу можно начать создавать эксплоит.
-
Сначала создаем файл
VboxSDS.log.11и накладываем на него блокировку; -
Используем COM-сервер для запуска службы;
-
Далее у нас срабатывает блокировка на файл и нам нужно после нее создать каталог
VboxSDS.log, который приведет к сбою службы; -
Продолжаем запускать службу до тех пор пока каталог не окажется пустым;
-
Как только каталог становится пустым, создается файл и устанавливается уступающая блокировка;
-
Запускаем службу заново и при срабатывании блокировки файл
VboxSDS.log.9удаляется и каталог превращается в точку соединения с каталогом NT Object Manager (\RPC Control); -
В каталоге Диспетчера объектов создаются две символические ссылки:
-
VboxSDS.log.9который указывает на нашу dll полезной нагрузки; -
VboxSDS.log.10который указывает на несуществующую dll вsystem32каталоге (в данном случаеwow64log.dll);
-
-
После создания файла
wow64log.dllзапускаетсяMicrosoft Edge Update Serviceи наша dll загружается вSYSTEMпроцесс.
Если тебе ручной способ эксплуатации не очень нравится, то предлагаю альтернативное решения для автоматизации нашей уязвимости. Для этого воспользуемся уже готовым решением с Github и попробуем эксплуатировать все это дело в два клика.
-
Переходим на этот репозиторий;
-
Скачиваем его в архиве;
-
Далее запускаем файл
VirtualBoxLPE_del/Source.cpp(здесь тебе потребуется Visual Studio); -
Собираем проект в удобном месте;
-
Повторяем действия с
VirtualBoxLPE_move/Source.cpp; -
Готовые PE-файлы закидываем в виртуалку и запускаем через cmd.
Готово! Привилегии администратора у тебя на руках. Все интуитивно понятно и просто. А что делать с этим дальше зависит только от твоей фантазии. Ну а теперь пришло время подводить итоги.
Подводим итоги
Сама по себе уязвимость носит разрушительный характер и имеет крайне необычную форму происхождения. На настоящий момент уязвимость еще не устранена, хотя разработчики о ней знают. Не забывай обновляться, ведь от этого зависит безопасность твоей ОС и данных. Также не забывай про другие способы злоупотребления средой виртуализации, убирай сетевые мосты, общие папки и так далее. Таким образом ты сможешь пресечь попытки эксплуатации, и превратить свой ПК в неприступную крепость.
Подпишись на LHMedia:
Life-Hack — Хакер / Хакинг
Новостной канал
Канал с бесплатными видео курсами
Юмор
ссылка на оригинал статьи https://habr.com/ru/articles/811261/
Добавить комментарий