j00sean/cve-2022-44666Техническое описание и PoC для CVE-2022-44666, уязвимости в элементе управления syslink в Windows Контакты, связанной с экранированием атрибута href, позволяющей удаленное выполнение кода через специально созданные файлы VCF/.contact и обработчик протокола LDAP.
Это история ещё об одной забытой 0day, полностью раскрытой более 4 лет назад [Джоном Пейджем (hyp3rlinx)][R.1]. Чтобы понять отчёт, нужно учитывать, что я тупой :-) И моя тупость заставляет меня идти более длинными путями для решения простых задач, но также приводит к поиску других способов эксплуатации некоторых багов. Почему я это говорю? Потому что я не смог быстро понять, что способ создать файл .contact — это просто перейти в папку «Контакты», чтобы создать контакт; вместо этого я использовал эту информацию, чтобы сначала создать VCF-файл, а затем ошибочно подумал, что это какой-то вариант. Это также произошло из-за того, что мой мозг не может понять, почему некоторые 0day забываются на такое долгое время ¯\(ツ)/¯ После того, как это было сделано и после ответов «не будет исправлено» от [MSRC][R.2] и [ZDI][R.3], были проведены дальнейшие исследования для повышения серьёзности, в конечном итоге были задействованы файлы .contact и обработчик URL-протокола Windows «ldap».
Пока я читал код эксплойта для [этой уязвимости][R.4], который на самом деле был опубликован как 0day, можно найти [отчёт ZDI][R.5].
Обновление от 21.07.2022: После сообщения об этом случае в MS, сотрудники MSRC справедливо указали мне, что Windows Contacts не является программой по умолчанию для открытия VCF-файлов.
Дальнейшее исследование всё же показывает, что программа по умолчанию для VCF-файлов в Win7 ESU и WinServer2019 — Windows Contacts (wab.exe), в противном случае используется MS People (PeopleApp.exe). Вот полная таблица этого тестирования:
В любом случае они всё ещё утверждают, что для эксплуатации бага требуется определённая социальная инженерия, такая как открытие специально созданного VCF-файла и клик по некоторым ссылкам, поэтому это не соответствует критериям MSRC для выпуска обновления безопасности.
Обновление от 25.07.2022: Что ж, после дальнейшего исследования это тот же баг. В итоге мне удалось найти proof of concept для файла .contact. На самом деле можно корректно распарсить файл .contact, используя HTML-сущности. Обратите внимание, это решает предыдущую проблему (Обновление от 21.07.2022), и этот формат файла (.contact) открывается Windows Contacts, программой по умолчанию для этого расширения, даже если в системе установлен MS Office. Требуется лишь первая ассоциация файла, если она ещё не была выполнена, но единственная программа, установленная по умолчанию для этого, — Windows Contacts.
Обновление от 25.07.2022: Это дальнейшее исследование привело меня к точке, к которой я стремился некоторое время назад: использовать какой-либо обработчик URL-протокола для автоматического открытия специально созданных контактных данных для эксплуатации бага. В итоге мне удалось заставить это работать благодаря схеме URI ldap, которая по умолчанию связана с приложением Windows Contacts. Таким образом, просто настроив мошеннический LDAP-сервер и передавая полезную нагрузку в атрибутах mail, url или wwwhomepage, влияние эксплуатации возрастает, поскольку теперь не требуется дважды кликать по вредоносному файлу VCF/Contact; мы можем доставлять это с помощью URL-протоколов.
Обновление от 08.02.2023: В качестве жеста доброй воли со стороны MSRC [Джон Пейдж (hyp3rlinx)][R.1] был включён на страницу благодарностей за обнаружение [CVE-2022-44666][R.10].
Отчёт в основном такой же, как по ссылкам выше, однако я немного улучшил социальную инженерию. На самом деле, первое, что я сделал, — это улучшил видимость ссылок, как если бы это была уязвимость XSS; на самом деле это HTML-инъекция, поэтому можно закрыть первый элемент привязки и вставить новый. Затем я хотел скрыть эти HTML-элементы из виду, так что простое задание как можно более длинного «innerHTML» было бы достаточным для их сокрытия (из-за ограничений на количество символов).
Вот финальная полезная нагрузка:```html URL;WORK:">CLICKMEEEEE...
Чтобы увидеть, что происходит, запустите procmon и настройте фейковый target атрибута href следующим образом:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
После нажатия на ссылку в procmon наблюдается такой вывод:
