playboisk8/poc-cve-2017-8464-opencalculatorExplotando la vulnerabilidad .lnk y los mecanismos de manejo del sistema operativo respecto a explorer.exe y las unidades USB.
Crea un acceso directo + 1 .DLL que contiene el payload malicioso => Ponlo en un USB y envíalo a la víctima => la víctima abre el USB => ¡El payload se activa automáticamente!
En primer lugar, necesitamos saber exactamente de dónde viene este error. Se debe a la función llamada Plug-and-Play (Conectar y usar). El sistema operativo detecta automáticamente el dispositivo, asigna recursos y carga el controlador adecuado para que funcione de inmediato sin necesidad de reiniciar. Cuando conectas un USB y abres la carpeta con el Explorador de Windows explorer.exe, el sistema operativo escanea los archivos para mostrar el icono correspondiente al usuario.
Desde las versiones antiguas de Windows, Microsoft quería que los accesos directos (shortcut .lnk) que apuntan a las funciones del Panel de control (que en esencia son archivos .cpl o .dll) pudieran mostrar iconos dinámicos de forma flexible. Por ello, la biblioteca principal de gestión de la interfaz de Windows, shell32.dll, fue diseñada con una función llamada CPL_LoadCPLModule.
Usar LoadLibrary a ciegas: Para obtener el icono desde el archivo de estructura del applet del Panel de control, el sistema operativo no lee un simple archivo de imagen estático, sino que utiliza la función LoadLibraryW para cargar directamente toda esa biblioteca de vínculos dinámicos en el espacio de memoria del proceso explorer.exe. Después de cargarla, llama a una función de exportación estándar, CPlApplet, para obtener el icono y dibujarlo en la pantalla.
Para demostrar que LoadLibraryW está realmente relacionado con la cadena de explotación anterior:
1/ Ejecuta
x64dbg với quyền admin2/ Adjunta
explorer.exe3/ Escribe el comando
bp LoadLibraryW4/ Pulsa F9 para que
explorer.execontinúe ejecutándose5/ Conecta el USB y de inmediato
hit breakpoint!
Me encontré con el problema de que la cadena del exploit estaba completamente silenciosa; aunque intentaba comprobar y depurar varias cosas, no podía encontrar la forma de arreglarlo. Después probé con el PoC de otra persona, pero también falló.
Sin embargo, cuando me fui a almorzar y volví, recuperé la concentración y la calma. Empecé a preguntarme por qué el PoC de este tipo funcionaba en su máquina y en la mía no. Vale, empecé a hacer ingeniería inversa ligera de su .lnk y .dll y descubrí dos cosas.
1 / Mi .dll es más larga que la del otro. ¡Pero no importa, ese no es el problema!
2 / Al pasar el .lnk por HxD para leer los strings, descubrí que este tipo no usa una ruta relativa, sino una absoluta.
Relativa: ../example.dll
Absoluta: O:/example.dll
Vale, ahora la solución es que necesitamos saber qué letra de unidad se asignará automáticamente al USB cuando se conecte a la máquina de la víctima. A partir de ahí, asignamos la ruta absoluta y tendrá éxito, porque en mi Win7, al conectar el USB, siempre aparece como unidad F, así que mi sintaxis de build es:
python Make_PoC.py FakeGoogleChrome F:\Pwned.dll
Debido a que este es un fallo de diseño de la arquitectura del sistema (Logic/Architecture Flaw) y no un desbordamiento de búfer, Microsoft tuvo que cambiar por completo la forma de gestionar el Panel de control:
.cpl o .dll cargados por procesos del sistema tengan una firma digital válida de Microsoft o estén en directorios del sistema estrictamente protegidos (como System32) para evitar el error de "Binary Planting" desde USB.explorer.exe [cite: 1058], las nuevas versiones de Windows ejecutan los applets del Panel de control a través de un proceso intermedio aislado (como dllhost.exe o rundll32.exe). Si la DLL se bloquea o contiene malware, solo derriba ese proceso intermedio y no puede controlar todo el sistema de interfaz de usuario.Investigación VN
PoC
Herramienta para crear el .lnk vulnerable