Антивирус (AV) - отличная цель для поиска уязвимостей: большая поверхность для различных видов атак, сложный анализ и различные компоненты, выполняющиеся с высокими привилегиями. Итак, пару месяцев назад я решил посмотреть последнюю версию Comodo Antivirus v12.0.0.6810. В итоге я нашел несколько классных вещей, которые, как мне показалось, стоило осветить здесь, - это побег из песочницы, а также повышение привилегий в SYSTEM. В этой статье мы будем злоупотреблять различными COM-объектами, обходя двоичные проверки подписи и угоняя сервисы. Я думаю, вы найдете это интересным, так что давайте начнем.
Comodo Sandboxing Primer
Во-первых, я хотел бы дать учебник по технологии песочницы Comodo, которую Comodo называет «сдерживание», в этой статье я буду использовать взаимозаменяемость «песочница» / «сдерживание». Эта технология ограничивает выполнение ненадежных приложений ( RTATC ) в среде, подобной песочнице, наряду с другими запущенными процессами в ОС. Он оснащен гибридом хуков пользовательского режима вместе с драйвером режима ядра, предотвращая любые изменения файлов или реестра на компьютере. Чтение файлов и реестра разрешено, но как только происходит запись, файловый ввод-вывод перенаправляется в файловую систему песочницы, а последующие чтения затем считываются из этой изолированной файловой системы, чтобы создать иллюзию того, что процесс взаимодействует с файловой системой.
Comodo выполняет это через свой драйвер фильтра Cmdguard.sys, который регистрирует _FLT_REGISTRATION структуру с помощью FltRegisterFilter API. Эта структура содержит процедуры обратного вызова для различных IRP, полученных из приложений пользовательского режима, такие как доступ к файлам, файл письмо и т.д., и может перехватить соответствующий образ. Также стоит отметить, что ALPC (тип Microsoft IPC, используемый для многих компонентов ОС) также является изолированной программной средой, которая перенаправляет попытки подключений ALPC к «изолированным» экземплярам svchost.exe, предотвращая выход из изолированной программной среды через RPC / ALPC. Ниже приведена иллюстрация того, как работает эта технология сдерживания.
Рисунок 1 - Иллюстрация с обратной технологией содержания Comodo
Cmdguard.sys не только фильтрует файловый ввод / вывод реестра, но также отслеживает запущенные процессы, регистрируя CREATE_PROCESS_NOTIFY_ROUTINE (используя PsSetCreateProcessNotifyRoutine ). По мере выполнения процесса, состояние защиты, уровень доверия и другие соответствующие атрибуты Comodo отслеживаются в списке процессов, хранящихся в ядре. Cmdguard.sys предоставляет «порты фильтра», с которыми могут взаимодействовать компоненты Comodo. Состояние "ограничения" устанавливается путем отправки определенного сообщения в его порт фильтра с именем «cmdAuthPort ». Целевой процесс, указанный в сообщении, имеет флаг «сдерживания», установленный драйвером режима ядра.
Guard64.dll (который внедряется практически в каждый запущенный процесс) отвечает за отправку этих сообщений об ограничениях из пользовательского режима после создания отдельного процесса. Например, Guard64.dll будет перехватывать API CreateProcessInternalW от Explorer.exe, так что когда пользователь выполняет ненадежный процесс, ловушка отправляет сообщение «сдерживание» в порт фильтра Cmdguard.sys. Теперь, когда запускается ненадежный процесс, он считается «содержащимся» драйвером и предотвращает ввод/вывод файла/реестра. Кроме того, Cmdguard.sys будет впрыскивать Guard64.dll в процессе, в замкнутых системах, которые будут выполнять агрессивное "сцепление".
Рисунок 2 - Процедура инъекции dll Cmdguard.sys
Ниже мы видим только несколько хуков пользовательского режима, которые установит Guard64.dll.
Рисунок 3 - Guard64.dll Usermode Hooks
Общая роль, которую играют эти ловушки, - это предотвращение подключения отдельных процессов к существующим защищаемым объектам, созданным автономными процессами. Для этого он добавит тег « !Comodo_6 » к каждому имени объекта, созданному или открытому отдельным процессом, предотвращая столкновение имен (или соединение) с существующими защищаемыми объектами в ОС.
Фактически, именно так работает его защитная оболочка RPC / ALPC! Трафик RPC / ALPC перенаправляется на содержащиеся экземпляры Svchost.exe (видно на первой диаграмме выше). Это связано с тем, что «!Comodo_6 » добавляется к именам портов, к которым пытались подключиться процессы, и содержащиеся экземпляры Svchost.exe создавали имена портов с « !Comodo_6 », добавленными к ним, поскольку они сами содержатся. Здесь мы видим, что отдельный установщик MSI пытается запустить его и в конечном итоге создает компонент службы MSIexec.exe, находящийся в песочнице, созданный (в cmdvirth.exe) после выполнения вызовов RPC.
Рисунок 4 - Содержит порождения ALPC, содержащиеся в экземпляре MSIExec
Обход этих хуков пользовательского режима тривиален, но избежать выхода из него непросто. Например, было невозможно просто пропатчить связанные с ALPC хуки и выйти через WMI, так как они также отслеживались и блокировались CmdAgent.exe. Теперь, когда я представил небольшой учебник по сдерживанию Comodo, давайте рассмотрим, как мы можем добиться побега и эксплуатации.
Создание Comodo COM-клиента
Comodo использует множество механизмов IPC между различными AV-компонентами: портами фильтра, общей памятью, LPC и COM. COM - это то, на чем мы сосредоточимся здесь. Хороший учебник для COM можно найти здесь, но вкратце он обозначает «Компонентная объектная модель» и представляет собой технологию Microsoft, позволяющую различным модулям создавать и взаимодействовать с различными объектами, определенными COM-сервером. COM-серверы могут быть локальными (просто dll COM-сервера, загруженного в текущий процесс) или удаленными, COM-сервер работает как удаленный процесс и взаимодействует через ALPC. С точки зрения эксплуатации, удаленный предоставляет гораздо более интересный сценарий.
Мы случайно узнали, что Comodo имеет возможность вызывать задания сканирования из процессов с низким уровнем привилегий, таких как explorer.exe (с помощью Context Shell Handler - (меню, которое появляется, когда пользователь щелкает правой кнопкой мыши)) или Cis.exe (графический интерфейс клиента Comodo). Эти задания сканирования выполняются путем вызова подпрограмм в CAVWP.exe, который запускается как SYSTEM.
Если мы сможем понять, как подключиться к этому сервису, то, возможно, мы сможем открыть для себя новую поверхность атаки и найдем даже более интересные функции, чем просто «сканирование». Это удаленное взаимодействие с CAVWP.exe происходит через COM, так как CAVWP.exe является COM-сервером вне процесса, как мы видим в реестре.
Рисунок 5 - CAVWP.exe COM-сервер
Давайте посмотрим, как Explorer.exe и COM-клиент Comodo удаленно запускают эти «сканирования» через COM. Как я упоминал ранее, одним из клиентов с низким уровнем привилегий, который может инициировать это сканирование, является обработчик контекстного меню оболочки Explorer.exe, который регистрирует Comodo - CavShell.dll
Рисунок 6 - Обработчик контекстного меню Comodo в Explorer.exe
Перевернув обработчик расширения оболочки, я обнаружил, где реализована COM-процедура «сканирования» клиента. Понимание этой функции даст нам ключи к тому, как успешно спроектировать наш собственный COM-клиент.
Рисунок 7 - Процедура сканирования файла Cavshell.dll (обработчик контекстного меню)
Этот конкретный вызов CoGetClassObject интересен. CoGetClassObject возвращает указатель на интерфейс для объекта, связанного с предоставленным CLSID. Просматривая CLSID в реестре, мы видим, что он предназначен для «Cis Gate Class», и вскоре понимаем, что CAVavWp.exe не имеет ничего общего с этим классом, и фактическим COM-сервером для этого класса является CmdAgent.exe.
Рисунок 8 - CLSID (CLSID_CisGate) показывает, что COM-сервером является Cmdagent.exe
Оказывается, CmdAgent действует как прокси между этими COM-клиентами с низким уровнем привилегий и CavWp, поскольку CavWp будет сканировать от имени вашего запроса к CmdAgent через интерфейс CisGate. Имейте в виду, моя главная цель здесь - просто настроить и понять эти начальные привязки, чтобы у нас была больше поверхность атаки.
После обратного инжиниринга клиента (а также небольшого количества самого CmdAgent) мы портируем COM-заглушки с соответствующими смещениями методов и реинжиниринг нашего кода, чтобы имитировать, что эти COM-клиенты делали и выполняли.
Рисунок 9 - Реорганизация «поддельного» Comodo COM-клиента
Одна проблема: подписание кода
Но запустить этот код не удается при вызове «CreateInstance» в CisClassFactory, так как он возвращает E_ACCESSDENIED . Это странно, поскольку у нас есть те же привилегии процесса, что и у Explorer.exe и Cis.exe (которые могут обойтись без таких вызовов). Почему мы не можем?
Здесь у нас есть CmdAgent.exe в отладчике, мы сломали там, где он получает вызов «CreateInstance», который мы сделали, и видим, что он разветвляется в специальное сообщение E_ACCESS_DENIED.
Рисунок 10 - Cmdagent.exe блокирует неподписанные процессы, взаимодействующие через COM
Это означает, что не Windows сообщает ACCESS_DENIED, а сама Comodo по собственному решению.
Это конкретное «решение» основано на проверке подписи, которая проверяет, что COM-клиент, запрашивающий экземпляр, является доверенным «подписанным» двоичным файлом. Глядя на подпрограмму проверки подписи в Cmdagent.exe, выяснилось, что подписавшими могут быть либо Comodo, либо Microsoft, и это имеет смысл, так как Explorer.exe или Cis.exe являются единственными ожидаемыми клиентами, которые должны вызывать COM-методы в CmdAgent. EXE.
Рисунок 11. Классы проверки подписи Cmdagent.exe (HardMicrosoftSigner / HardComodoSigner)
Проверка подписи была просто обойдена, однако ... подождите ... посмотрим, сможете ли вы увидеть проблему. Вот CmdAgent.exe, разрешающий имя процесса COM-клиента для последующей проверки подписи с диска:
Рисунок 12 - Cmdagent.exe Поиск полного имени COM-клиента
Как вы, возможно, знаете, GetModuleFileNameEx просто запрашивает у целевого процесса ' PEB- > Ldr-> InMemoryOrderModuleList для полного имени изображения. Это находится под нашим контролем, конечно, и может быть легко изменено в рамках нашего собственного процесса.
Альтернативное решение этой проблемы заключается в том, чтобы вводить доверенный двоичный файл Microsoft или Comodo и отправлять оттуда наши COM-запросы. Comodo, тем не менее, предотвращает внедрение DLL, поэтому для того, чтобы осуществить это, мы должны обработать полый доверенный двоичный файл Comodo.
Это более громоздкий маршрут, чем манипулирование нашим собственным PEB, но он дал нам большие преимущества. Одним из них является то, что драйвер Cmdguard.sys НЕ будет внедрять Guard64.dll, который нас раздражает. Ниже показан Cmdguard.sys и как он вызывает процедуру «InjectDll», только если процесс считается «ненадежным». «IsProcessUntrusted» пройдет, если мы опустошим C:\Program Files\COMODO\COMODOInternet Security\CmdVirth.exe, например, потому что драйвер доверяет в соответствии с исполняемым путем, который мы имитируем, когда мы опускаем такой доверенный процесс.
Рисунок 13 - Cmdguard.sys пропускает инъекцию Guard64.dll, если процесс является «доверенным»
Теперь мы добавляем подпрограмму обработки процесса, которая выделяет экземпляр « C:\Program Files\COMODO\COMODOInternet Security\CmdVirth.exe» (подписанный Comodo) и заменяем исполняемый код нашим собственным. Этот внедренный код теперь будет выполнять те же процедуры COM, что и раньше, за исключением того, что теперь он пройдет проверку подписи, а также не имеет хуков. Мы повторно запустили код и успешно запустили задание на сканирование с нашим низким уровнем привилегий и состоянием!
Рисунок 14 - Ура! Мы успешно запустили сканирование с нашего нестандартного COM-клиента
Охота на злоупотребляющие COM-интерфейсы
Работая со сканированием (из отдельного процесса), мы можем теперь искать более интересные COM-интерфейсы для атаки CmdAgent. Глядя на другие ~ 60 методов для интерфейса CisGate, которые мы получили, они, честно говоря, не выглядели слишком интересными, и те, справедливо использовали CoImpersonateClient, который предотвращает логические ошибки, к которым я стремился. Помните, как мы используем CreateInstance для создания объекта CisGate в CmdAgent.exe? Вероятно, мы можем создать больше объектов, каждый из которых имеет больше методов для атаки. Вернуться к CmdAgent!
Функция ICisClassFactory-> CreateInstance создает требуемый объект и возвращает запрошенный указатель интерфейса для него, заключая вызов CisGate-> QueryInterface. Для тех, кто не знает, QueryInterface является базовой функцией в IUnknown, базовом классе, от которого наследуются все COM-классы. Вкратце, эта функция разрешает riid (идентификатор интерфейса) для интерфейса объекта, чтобы клиент (такой как мы) мог вызывать методы для него. Обладая этими знаниями, мы м
ункцию QueryInterface CmdAgent.exe и наблюдая за ее поддерживаемыми интерфейсами.
Рисунок 15 - Поддерживаемые интерфейсы CmdAgent.exe
Мы определили список поддерживаемых_интерфейсов, которые поддерживает их QueryInterface, и назвали каждый GUID, найденный в нашем реестре. RID IID_ICisFacade - это тот, который используется для возврата объекта CisGate. Был там - сделал это. Следующим интересным является IID_IServiceProvider. Читая о IID_IServiceProvider, он звучал так, как будто он может привести к разным интересным вещам. Ища GUID IID_IServiceProvider в Cis.exe (клиент Comodo GUI), мы обнаруживаем, что он используется. Если можно поменять местами путем конструирования, это даст нам хорошее представление о том, как использовать его самостоятельно, какие услуги они пытаются получить и для чего делают.
Реестр
Вот Cis.exe и как я нашел его, используя «IServiceProvider» для QueryService . Он использует его для получения заданного в Comodo объекта «SvcRegistryAccess».
Рисунок 16 - Cis.exe Получение ISvcRegistryAccess
Конкретное использование в Cis.exe показало, что он получает объект SvcRegistryAccess от CmdAgent.exe, а затем вызывает для него метод для чтения ключа реестра и отправки данных обратно. Наличие для вас процесса SYSTEM чтения реестра для вас уже звучит как интересный вектор атаки, но у меня также было предчувствие, что разработчики не просто сделали этот SvcRegistryAccess классом «только для получения». Вернитесь к CmdAgent, чтобы увидеть, как реализован этот класс COM.
В CmdAgent мы видим, что метод ISvcRegistryAccess, который они вызывали удаленно, напрямую считывает значение reg и возвращает данные клиенту без CoImpersinateClient . Потрясающие! это означает, что мы можем читать значения реестра как SYSTEM, так как это уровень привилегий, в котором работает CmdAgent.
Рисунок 17 - CmdAgent.exe ISvcRegistryAccess - метод чтения реестра (как SYSTEM - без олицетворения)
Реестр
Теперь давайте посмотрим, поддерживает ли этот COM-объект записи реестра. Обойдя его vtable, мы видим метод, который вызывает метод RegSetValueExW.
Рисунок 18 - CmdAgent.exe показывает более интересные методы для вызова (установка значений реестра)
Рисунок 19. Метод CmdAgent.exe ISvcRegistryAccess устанавливает значение реестра (как SYSTEM - без олицетворения)
Кажется довольно ясным, что если мы вызовем этот метод, мы можем получить запись в реестр как SYSTEM, так как я не вижу вызываемых API подражания. Мы изменяем наш код COM-клиента, чтобы получить IServiceProvider и разрешить ISvcRegistryAccess, а затем вызвать этот метод «записи в реестр». Если мы посмотрим, как мы получили наш regInterface с помощью вызова «GetRegInterface», мы фактически увидим, что реализация CmdAgent.exe создала только дескриптор reg-ключа только для чтения, поэтому, конечно, попытка вызвать метод «write registry» приведет к ACCESS_DENIED. К счастью, я нашел другой метод в таблице ISvcRegKey, который заменяет наш дескриптор ключа реестра на «writable», передавая некоторые дополнительные аргументы.
Мы просто добавляем вызов к этому методу с правильными аргументами, чтобы получить доступный для записи ISvcRegistryAccess.
Рисунок 20. Модификация нашего COM-клиента для получения доступного для записи интерфейса реестра
Собрав все это вместе, мы придумаем следующий код и получим запись в реестре как SYSTEM!
Рисунок 21 - наш окончательный код COM-клиента
Рисунок 22 - Успешно перезаписаны данные в привилегированном разделе реестра
Эксплуатация в СИСТЕМУ
Сверху мы запускаем наше изолированное приложение, которое затем обрабатывает двоичный файл с подписью Comodo (чтобы обойти проверку подписи CmdAgent), который затем запускает наш COM-код, который мы написали, и выполняет запись в реестр как SYSTEM из нашего «содержащегося» процесса. Практическим выходом из этого было бы перехватить существующий сервис, а достойным сервисом для перехвата был сам CmdAgent.exe. Заменим ImagePath данные в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CmdAgent, это заменит службу CmdAgent нашей собственной, которая будет работать как система.
Рисунок 23 - служба CmdAgent.exe в реестре
Однако нам потребуется перезапуск службы CmdAgent, если мы хотим мгновенно получить эти привилегии SYSTEM (в отличие от ожидания следующего перезапуска). К счастью, у нас есть способ сделать это, поскольку я нашел способ, которым мы можем аварийно завершить работу CmdAgent, что приведет к «оживлению» службы и по ошибке запустит наш ImagePath, который мы написали в защищенный раздел реестра. Сбой CmdAgent очень прост, так как процесс предоставляет объект структурных данных Section, который может записывать все:
Рисунок 24. Объект раздела CmdAgent.exe, предоставляющий доступ к данным для записи (SharedMemoryDictionary)
CmdAgent ссылается на этот буфер как «SharedMemoryDictionary», который представляет собой целый объект класса, только что представленный в разделяемой памяти. Мы можем потерпеть крах, записав данные неправильного размера в члены объекта, что приведет к чтению за пределами границ, и когда CmdAgent пытается прочитать этот SharedMemoryDictionary (который постоянно), будет сбой CmdAgent. Когда сервис возрождается, он запускает наш новый двоичный файл, который мгновенно переводит нас в SYSTEM.
Рисунок 25 - Успешное повышение до SYSTEM
PoC
Код: https://github.com/tenable/poc/tree/master/Comodo/Comodo%20Antivirus
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://medium.com/tenable-techblog/comodo-from-sandbox-to-system-cve-2019-3969-b6a34cc85e67
