playboisk8/poc-cve-2017-8464-opencalculatorЭксплуатация уязвимости .lnk и механизмов обработки операционной системой explorer.exe и USB-накопителей.
Создаём 1 ярлык + 1 .DLL с вредоносной нагрузкой => закидываем на USB и отправляем жертве => жертва открывает USB => нагрузка активируется автоматически!
Прежде всего, нам нужно точно знать, из-за чего возникает эта ошибка! Всё дело в функции под названием Plug-and-Play (Подключи и играй) — ОС автоматически обнаруживает устройство, выделяет ресурсы и загружает подходящий драйвер, чтобы оно заработало сразу, без перезагрузки компьютера. Когда вы вставляете USB и открываете папку через Windows Explorer explorer.exe, операционная система сканирует файлы, чтобы отобразить пользователю соответствующие значки (иконки)!
Начиная со старых версий Windows, Microsoft хотела, чтобы ярлыки (.lnk), указывающие на функции Панели управления (по сути, файлы .cpl или .dll), могли гибко отображать динамические значки. Поэтому в базовой библиотеке управления интерфейсом Windows shell32.dll была спроектирована функция с названием
Слепое использование LoadLibrary: Чтобы получить значок из файла-апплета Панели управления, операционная система не читает просто статический файл изображения, а использует функцию LoadLibraryW для прямой загрузки всей динамически подключаемой библиотеки в адресное пространство процесса explorer.exe. После загрузки она вызывает стандартную экспортируемую функцию CPlApplet, чтобы получить значок и отрисовать его на экране
Чтобы доказать, что LoadLibraryW действительно связана с приведённой выше цепочкой эксплуатации:
1/ Включите
x64dbg с правами администратора2/ Подключитесь к
explorer.exe3/ Введите команду
bp LoadLibraryW4/ Нажмите F9, чтобы
explorer.exeпродолжил работу5/ Вставьте USB — и сразу
сработает брейкпоинт!
У меня была проблема: цепочка эксплойта полностью молчала, сколько бы я ни пытался проверить и отладить всё что можно, найти способ исправить не удавалось! Затем я попробовал найти чужой PoC и запустить его, но тоже безуспешно!
Однако, когда я ушёл на обед и вернулся, ко мне снова пришли сосредоточенность и спокойствие. Я начал задаваться вопросом: почему PoC этого парня работает, а на моей машине — нет? Окей, я начал слегка дизассемблировать его .lnk и .dll и обнаружил две вещи!
1 / Мой .dll длиннее, чем у него! Но это не страшно, это не проблема!
2 / Когда я кинул .lnk в HxD, чтобы прочитать строки, я обнаружил, что этот парень использует не относительный путь, а абсолютный!
Относительный: ../example.dll
Абсолютный: O:/example.dll
Окей, теперь решение будет таким: нам нужно узнать, какой буквой диска автоматически обозначается USB при подключении к машине жертвы, затем прописать абсолютный путь — и всё получится, потому что на моей Win7 при подключении USB он всегда появляется как диск F, так что синтаксис сборки у меня такой:
python Make_PoC.py FakeGoogleChrome F:\Pwned.dll
Поскольку это ошибка проектирования архитектуры системы (логическая/архитектурная уязвимость), а не переполнение буфера, Microsoft пришлось полностью изменить способ обработки Панели управления:
.cpl или .dll, загружаемые системным процессом, имели действительную цифровую подпись Microsoft или находились в строго защищённых системных каталогах (например, System32), чтобы избежать ошибки "Binary Planting" с USB.explorer.exe [cite: 1058] новые версии Windows запускают апплеты Панели управления через изолированный промежуточный процесс (например, dllhost.exe или rundll32.exe). Даже если DLL упадёт или будет содержать вредоносный код, она лишь обрушит этот промежуточный процесс, но не сможет получить контроль над всей пользовательской интерфейсной системой.Исследование VN
PoC
Инструмент для сборки уязвимого .lnk