Repository navigation
Oportunidades
#5227
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Se identificaron oportunidades para reforzar la autenticidad de descargas, reducir solicitudes externas prescindibles y hacer más visibles las dependencias que ejecutan código con permisos elevados. No se encontró evidencia que permita afirmar que WinUtil contiene malware o que exporta automáticamente documentos del usuario. Tampoco se demostró una explotación ni se realizó una auditoría integral de los binarios externos.
El problema principal es la confianza transitiva: algunas acciones descargan contenido externo mutable y lo ejecutan o incorporan a configuraciones sensibles. HTTPS protege el transporte, pero no fija el contenido a una revisión aprobada ni protege frente al compromiso del origen de publicación.
La propuesta es conservar las funciones y añadir controles de autenticidad, versionado, privacidad y recuperación, preferentemente en cambios pequeños y revisables.
Alcance y límites
• Se recuperaron 429 archivos de texto; se excluyeron 19 imágenes PNG.
• El inventario contiene 1102 cadenas URL/plantillas distintas. Incluye catálogos, documentación, namespaces XML, pruebas y dependencias de desarrollo: no son 1102 conexiones ejecutadas por WinUtil.
• Las referencias se clasificaron por contexto. La clasificación automatizada requiere revisión manual cuando una referencia tiene varios usos.
• No se ejecutó WinUtil, no se capturó tráfico en Windows, no se explotaron sistemas y no se inspeccionaron todos los paquetes/binarios externos.
• Las fuentes externas consultadas son las disponibles durante la revisión; las ramas y respuestas mutables pueden cambiar y no representan necesariamente versiones históricas.
• Las prioridades siguientes son de corrección y revisión. No son puntuaciones CVSS ni declaraciones de vulnerabilidades explotables confirmadas.
Hallazgos y mejoras
Prioridad: alta para revisión.
En Install-WinUtilChoco.ps1, línea 17, se descarga el bootstrap de Chocolatey y la línea siguiente ejecuta su contenido. El llamador no comprueba previamente una firma o un hash aprobado. La instalación del perfil PowerShell, línea 43 también apunta a un setup de una rama mutable y lo ejecuta en un proceso hijo.
Condición de riesgo: compromiso del origen, publicación o dependencias que cambie el contenido recibido. No se demostró que haya ocurrido. La mera existencia de una descarga remota no permite a cualquier atacante modificarla.
Mejoras propuestas:
• Descargar a un archivo temporal exclusivo; separar descarga, verificación y ejecución.
• Fijar versiones o commits revisados para scripts que sea viable fijar.
• Distribuir hashes esperados mediante un manifiesto autenticado; obtener archivo y hash de la misma fuente mutable no resuelve por sí solo el compromiso de esa fuente.
• Mostrar qué componente externo se ejecutará, su procedencia y su alcance.
• Revisar las opciones de entorno heredadas por el bootstrap, incluidos proxy, versión y URL alternativa de descarga.
Criterio de aceptación: un archivo benigno modificado, un manifiesto inválido o una verificación fallida deben impedir la ejecución y generar un registro local claro. Probarlo únicamente en laboratorio.
Prioridad: alta para revisión.
• O&O ShutUp10++, línea 9: descarga mediante Save-WinUtilFile y posteriormente ejecuta el archivo. El ayudante de descarga no verifica firma/hash.
• AutoLogon, línea 3: descarga e inicia un EXE sin comprobación explícita previa en esa función.
• ViVeTool, línea 481: descarga un ZIP versionado, lo extrae y ejecuta durante el flujo de instalación desatendida; ese bloque no fija un hash esperado.
Mejoras propuestas: reutilizar una política de validación común, comprobar firma válida y editor esperado cuando exista Authenticode, usar hash/versiones aprobados, controlar destinos y redirecciones, y emplear temporales exclusivos. Validar también arquitectura y rutas de extracción de archivos ZIP. No usar una ruta de recuperación que omita controles cuando falle una verificación.
Criterio de aceptación: rechazar firma inválida, editor inesperado, hash diferente, archivo incompleto y contenido no compatible antes de iniciar cualquier proceso.
Control positivo existente: la ruta MSI de PowerShell ya comprueba hash cuando existe digest y exige firma de Microsoft. Es una base útil; no todas las descargas carecen de controles. Una firma válida tampoco certifica ausencia de vulnerabilidades.
Prioridad: alta para revisión del alcance.
La lectura del setup externo mostró descarga del perfil, un tema, fuentes e instalación de módulos/programas adicionales. El perfil externo contiene actualización desde main y una rutina invocada al cargarlo que comprueba si corresponde actualizar; el intervalo predeterminado observado es de siete días, sujeto a condiciones de sesión. No se trata de una tarea programada de Windows.
Comparar el hash local y remoto para detectar cambios no autentica el contenido remoto. El perfil también define pubip, que consulta https://ifconfig.me/ip cuando se invoca; no se comprobó una consulta automática a ese servicio al iniciar.
Mejoras propuestas: explicar que instalar el perfil cambia futuras sesiones, permitir una versión fija sin autoactualización y documentar todas las dependencias transitivas. Separar esta función de los ajustes de rendimiento básicos.
Criterio de aceptación: tras instalar una versión fija, abrir nuevas sesiones no debe sustituir código sin la política de actualización elegida por el usuario.
Prioridad: alta para revisión de integridad y reversión.
En config/tweaks.json, línea 1121, el texto de una lista remota se agrega al archivo hosts. Si cambia su contenido, podría bloquear o redirigir nombres. No es ejecución PowerShell del texto descargado en ese bloque.
La muestra obtenida desde la ruta raw correspondiente contenía 948 entradas de mapeo, todas hacia 0.0.0.0, sin redirecciones públicas detectadas. Esto no valida todos los dominios ni el contenido futuro. La URL original falló en el lector; se consultó la ruta raw alternativa y no se comprobó equivalencia por redirección.
Mejoras propuestas: validar el formato, limitar IP y dominios admitidos, mostrar diferencias, evitar duplicados y mantener un bloque administrado identificable. Respaldar y revertir únicamente las entradas propias, preservando cambios ajenos.
Criterio de aceptación: rechazar contenido inesperado; aplicar dos veces sin duplicar y deshacer sin eliminar entradas del usuario.
Prioridad: media para privacidad.
La creación de entradas, línea 65 solicita iconos a Google Favicons usando el enlace del programa. No demuestra envío del inventario de aplicaciones instaladas. La consulta de patrocinadores se activa desde su opción de interfaz.
Mejoras propuestas: iconos incluidos localmente o marcadores sin red; datos de patrocinadores estáticos u opción explícita para cargarlos. Documentar las conexiones que realiza cada acción.
Criterio de aceptación: con la red bloqueada deben funcionar interfaz, búsqueda y catálogos. Con la red habilitada, una captura debe confirmar que esas acciones no producen solicitudes prescindibles.
Prioridad: media, dependiente de configuración.
La documentación de Microsoft indica que WinGet puede escribir eventos ETW que Windows puede enviar a Microsoft y dispone de telemetry.disable. No se verificó el estado efectivo ni el tráfico en un equipo. Desactivar ese ajuste no desactiva toda la telemetría de Windows ni la de los instaladores.
Cambiar DNS modifica el destino de futuras consultas del sistema; el benchmark conecta a servidores habilitados por configuración. No se debe interpretar cada dirección del catálogo DNS como conexión automática al abrir WinUtil.
La ruta de exportación de diagnóstico examinada escribe archivos locales y ofrece incluir logs; no se identificó una carga HTTP dentro de esa ruta. Los registros pueden contener rutas y detalles sensibles antes de compartirse manualmente.
Mejoras propuestas: informar del comportamiento de WinGet, ofrecer una política de privacidad sin modificar silenciosamente preferencias existentes, mantener DNS actual por defecto y añadir vista previa/redacción opcional de datos en informes.
Criterio de aceptación: comprobar configuración efectiva y tráfico por proceso en Windows; verificar exportación local sin carga automática y reversión de cambios DNS.
Prioridad: media/alta según permisos y flujo.
Los workflows contienen referencias a acciones externas mediante etiquetas. Conviene fijar su contenido y revisar permisos, secretos y publicación. La guía oficial de GitHub recomienda bloqueo de dependencias de workflows cuando esté disponible o referencias a SHA completo, junto con revisión del código.
El lockfile npm del sitio contiene 471 paquetes con resolved, todos con integrity. Es un control positivo de integridad, no prueba de ausencia de vulnerabilidades. No se consultaron avisos para cada paquete ni se analizaron todas las dependencias transitivas.
Mejoras propuestas: fijación verificable de acciones, permisos mínimos por job, separación entre pruebas y publicación, revisión de cambios en workflows, análisis periódico de dependencias y releases con manifiesto autenticado. Mantener las herramientas del sitio aisladas del equipo de trabajo.
Criterio de aceptación: probar la construcción de una versión identificada, bloquear publicación con verificaciones fallidas y documentar la procedencia del artefacto. No se exige igualdad byte a byte entre compilaciones si fecha, firma u otros campos variables no se han normalizado.
Orden sugerido de implementación
Separar cada mejora en un PR pequeño con su prueba. Preservar las funciones existentes y no aplicar cambios de sistema fuera de las acciones seleccionadas.
Estado de comprobación
Este informe se comparte como propuesta de revisión y endurecimiento. Si futuras pruebas revelan una vía de explotación concreta, comunicar primero los detalles sensibles mediante el proceso de seguridad del proyecto antes de publicarlos.
All reactions