Esto solo aplica a Windows. El resto de sistemas están libres en principio.
¿Qué está pasando?
No voy a extenderme demasiado, pero los famosos asistentes para solución de problemas tienen la culpa.
El CVE por si os interesa, CVE-2022-30190.
¿A alguien alguna vez el asistente de algo de windows le ha resuelto algo con una respuesta que no sea de las clásicas de Capitan Obvious?
Y aquí una de las múltiples pruebas que existen. Gracias a su autor onecloudemoji.
Como la respuesta ni está ni se la espera, voy a desarrollar aquí la versión doméstica de la contingencia que de momento viene tanto de las investigaciones de muchos investigadores como finalmente de Microsoft que parece ser, estaban informados de esto desde hace meses.
Además. Afecta a cualquier versión de Windows desde XP (2003 creo que se libra pero no estoy seguro) y el protocolo está ahí desde antes pero se empezó a usar en serio con Windows Vista.
Para todo esto hacen falta permisos de administrador.
Primer paso: Registro
En el registro tenemos una cosa llamada “hive”, madriguera. Y en la primera de ellas es donde están todos los objetos que dicen a la shell de windows como debe ejecutarse cada cosa, o más bien, quien debe ejecutar cada cosa.
Para el servicio de diagnóstico tenemos una serie de ejecutables y un protocolo de disparo.
Aquí vamos a tocar el protocolo.
En la clave Computer\HKEY_CLASSES_ROOT\ms-msdt dentro de regedit podemos encontrarlo.
La idea primera que se nos ocurrió para hacer ver a los usuarios era cambiar la ejecución del protocolo haciendo que el ejecutable lanzase un mensaje, en el propio notepad por ejemplo, en lugar del clásico asistente.
Pero si algo caracteriza a los usuarios medios es la popa predisposición a leer y mucho menos a seguir instrucciones así que el cartel que rezaba:
El asistente de solución invocado no se encuentra disponible por orden del SOC. Para contactar con el SOC consulte su caso mediante un ticket a HelpDesk. No se atenderá ninguna petición de soporte por otras vías.
Y el caso es que el texto les ha molado a los jefes pero no ha podido ser por experiencias pasadas.
Primera solución: Eliminación del hive
Bueno, pues eso. Todos nuestros proveedores de seguridad, y otros consultados adicionalmente coinciden que, aunque se deje vacía la clave de ejecución de shell en el registro (podéis ver el fichero adjunto en este enlace la clave de la que hablo), el tener aún acceso al hive permite que SCF o algún parcheo/reparación de Windows lo restaure.
Así que sin mucho sentido pero es como sopla, hemos decidido que la idea de eliminar completamente Computer\HKEY_CLASSES_ROOT\ms-msdt es la vía, y eso hemos hecho.
Segundo paso: El ejecutable
También sabemos que un parche lo va a cambiar, pero al menos me permite llevar un control de a quien se le ha aplicado la contingencia.
El ejecutable está en %SystemRoot%\system32\msdt.exe y lo que hemos hecho en el script es renombrarlo con la fecha de cuando se ha aplicado el proceso.
Para un usuario doméstico, con renombrarlo a .old (si habilita las extensiones y las ve) o borrarlo directamente, debería sobrar. De hecho es lo que he hecho en un par de máquinas que tengo en casa.
Por cierto. Es un ejecutable muy bien protegido. Hay que hacer más cosas que pongo abajo. Solo especifico la forma de hacerlo por consola pero se puede hacer por interfaz gráfica tambén.
Segunda solución: Eliminación del ejecutable
Pues lo mismo. Nuestros proveedores de seguridad también han dicho que mejor que renombrar, eliminar.
El caso es que se haga cualquiera de las dos actuaciones.
Empresas, y otros sitios grandes
Todo esto saltó porque desde un documento de Word se pudo invocar una elevación de permisos vía protocolo MS-msdt el cual queda demostrado que con un payload lo suficientemente grande y la invocación directa del asistente, tenemos un vector de ataque con una superficie casi infinita.
No solo ficheros de Word. También correos, páginas web, con un navegador y código en javascript es posible hacerlo, o con cualquier vector de los actuales.
El problema está localizado. Es la existencia de ese ejecutable, y el vector me recuerda a las variantes de acceso a otras cosas que surgieron después de que apareciera el bug del log4j.
Además se junta que una base de varios miles de usuarios con facilidad para abrir adjuntos, es una superficie expuesta muy extensa.
De ahí que nosotros que hemos podido lo hayamos hecho mediante GPO y un par de scripts en powershell que borran el hive de regedit (no he encontrado el admx que lo hace) y que renombran msdt.exe a msdt.exe.AAAAMMDD dejando así constancia de cuando se ha aplicado la contingencia.
El problema viene de que es un ejecutable protegido.
PS C:\WINDOWS\system32> takeown /f .\msdt.exe
SUCCESS: The file (or folder): "C:\WINDOWS\system32\msdt.exe" now owned by user "LABSAM-3\Sistemas".
PS C:\WINDOWS\system32> icacls .\msdt.exe /T /grant administrators:F
processed file: .\msdt.exe
.\config\systemprofile\AppData\Local\Microsoft\Windows\INetCache\Content.IE5\*: Access is denied.
Successfully processed 1 files; Failed processing 1 files
PS C:\WINDOWS\system32> move .\msdt.exe .\msdt.exe.20220601
PS C:\WINDOWS\system32> dir .\msdt.exe.*
Directory: C:\WINDOWS\system32
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 12/7/2019 10:09 AM 431104 msdt.exe.20220601
Para hacerlo, tan solo es necesario un terminal (ps, cms o wsl) y permisos de administrador.
Con esto sería suficiente para un Windows en inglés o MUI:
takeown /f C:\WINDOWS\system32\msdt.exe
icacls C:\WINDOWS\system32\msdt.exe /T /grant administrators:F
move C:\WINDOWS\system32\msdt.exe C:\WINDOWS\system32\msdt.exe.20220601
En español el comando icacls invocará otro grupo:
takeown /f C:\WINDOWS\system32\msdt.exe
icacls C:\WINDOWS\system32\msdt.exe /T /grant administradores:F
move C:\WINDOWS\system32\msdt.exe C:\WINDOWS\system32\msdt.exe.20220601
De esto, recuerdo haber escrito hace mucho en mi blog viejo.
Esta entrada ha sido creada en plan “emergencia” solicitada por @rfog42 de Wintablet.
YoVirtualizador en formato podcast. Ahora también en Sospechosos Habituales: https://feedpress.me/sospechososhabituales
Sin más, os dejo los enlaces:
Web: https://www.yovirtualizador.com
Grupo de telegram: https://t.me/grupovirtualizador
Podcast: https://www.ivoox.com/podcast-yovirtualizador_fg_f1563806_filtro_1.xml
Canal de youtube: https://www.youtube.com/channel/UC0R70cABSsmC6TFyXth0qPg
Enlace de afiliados de amazon: https://amzn.to/3gX3HmK
Enlace de referidos de la Asociación Podcast: https://www.asociacionpodcast.es/registrarse/socio/?coupon=SB6A70
