Nueva información para los usuarios e interesados de la herramienta de Windows Classic Shell: El proyecto de seguimiento ya ha sido renombrado de nuevo y ahora se llama Open Shell Menu. Aquí hay algo de información y una pista de por qué yo (actualmente) diría «ten cuidado».

Publicidad

Hay software que se mantiene en el foco de atención a través del cambio de nombre. Yo clasificaría el proyecto Classic Shell en esta categoría, porque este proyecto ha sido renombrado de nuevo.

Algunos antecedentes

El desarrollador del Classic Shell, Ivo Beltchev, dejó de desarrollar el software hace algún tiempo. Pero cedió el código fuente a la comunidad para su posterior mantenimiento. He publicado sobre eso en mi blog alemán.

Pero lo que no es tan agradable para mi gusto: Por el momento el proyecto produce actualmente sólo titulares debido a múltiples renombramientos. Durante un tiempo la herramienta se llamó Classic Start. Luego la comunidad decidió renombrarla a finales de julio de 2018 a NeoClassic-UI/Menu. Tal vez haya buenas razones, no lo sé, nunca se han mencionado.

El siguiente nuevo nombre …

Y ahora el proyecto ha sido renombrado a Open-Shell-Menu. El archivo de instalación actual se llama ahora OpenShellSetup_4_4_126.exe, pero la funcionalidad probablemente no ha cambiado. El proyecto está disponible en GitHub, pero no todos los enlaces son funcionales todavía. La actual Nightly Build está disponible aquí, que expira después de 6 meses.

El lado oscuro de este proyecto: Seguridad

Además del ‘se cayó un saco de arroz en China, por favor, continúe, no hay nada que ver’, me gustaría señalar que deberías mantener tus manos lejos de esta herramienta (al menos, hasta que los desarrolladores hayan arreglado algunas cosas fundamentales). ¿Por qué esta advertencia?

Publicidad

Estoy en contacto con el hacker de sombrero blanco Stefan Kanthak (ver) desde hace tiempo (Microsoft lo alista en el Top 100 MSRC 2017 y también en otras listas, como el top 100 Finders en 2015). investigador en 2015 (ver).

Stefan Kanthak ha publicado un comentario en alemán, esbozando algunas cuestiones críticas. He aquí un breve extracto:

  • Para mayor comodidad, los desarrolladores entregan un instalador .exe (en lugar de un archivo .msi). Este instalador debe ejecutarse con privilegios administrativos para instalar el software. El instalador desempaqueta los archivos necesarios en un directorio TEMP (desprotegido). Problema: Si hay un malware en el sistema que actualmente sólo se ejecuta con los derechos de una cuenta de usuario restringida, se activa la trampa.
  • Este malware puede darse cuenta del proceso de desempaquetado (hay APIs de Windows que pueden informar de esto y llamar a una «función gancho» del malware). A continuación, basta con copiar un archivo DLL con un nombre determinado en la carpeta TEMP (como está desprotegida, esto es posible con derechos de usuario limitados).
  • Durante el proceso de instalación, el instalador intenta cargar la supuesta DLL de Windows, pero accede a la DLL colocada por el malware debido a las características de Windows. Y el malware recibe rápidamente derechos administrativos a través de la DLL.

Esto se conoce desde hace tiempo como secuestro de la orden de búsqueda de la DLL, un riesgo potencial para la seguridad y debe ser absolutamente evitado. Stefan Kanthak ha publicado algunos enlaces y más detalles en su comentario en alemán. Como conclusión: Mientras el proyecto no se ocupe de estos problemas, yo evitaría/tendría cuidado al usar dicho software.

Addendum: En este punto tengo que retractarme un poco. He echado un vistazo al instalador (bajo Windows 7). Una observación interesante: El lector alemán Martin Feuerstein había señalado en un comentario, que el instalador .exe tiene un interruptor para extraer los instaladores .msi – se puede mostrar con /? Así que usted puede descomprimir el .msi e instalar la versión de 32/64 bits a través del instalador .msi.

Hay otra observación: Aparentemente el instalador .exe se ejecuta durante el desempaquetado sólo con derechos de usuario estándar, desempaqueta los archivos .msi y llama al que corresponda. El instalador .msi activa el aviso UAC debido a la configuración dentro de su manifiesto e instala la herramienta. Esto elimina el vector de ataque descrito anteriormente según mis conocimientos actuales (si el msi correcto llama al UAC se puede comprobar en el prompt UAC). Si hay nuevos hallazgos, los añadiré.

Addendum 2: Según Stefan Kanthak el instalador ClassicStartSetup_4_4_109.exe tiene las siguientes dependencias – puede obtenerse con:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe

COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll

Y las DLLs anteriores dependen de GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll y
SHLWAPI.dll. Desde Windows Vista VERSION.dll no es una «DLL conocida» y cualquier archivo con ese nombre se cargará desde el directorio de la aplicación, si está presente. Lo mismo ocurre con SECUR32.dll y RPCRT4.dll.

Nota: En las capturas de pantalla que aparecen a continuación y en el comando de ejemplo, utilizo el antiguo ClassicStartSetup_4_4_109.exe. He realizado las mismas pruebas con OpenShellSetup_4_4_126.exe (la versión nocturna más reciente) – el mismo resultado. Tampoco hay firma digital disponible. Por lo tanto, dejo las capturas de pantalla y los comandos antiguos dentro del texto.

Stefan Kanthak me permitió utilizar algunas de sus DLL de prueba para ejecutar ClassicStartSetup_4_4_109.exe en un entorno de prueba. Este es el resultado:


(Click to zoom)

Un intento de mostrar las opciones resultó en una advertencia, de que un malware podría haber manipulado los archivos (cuadro de diálogo delante). Después dejé que el instalador .exe sólo extrajera los instaladores .msi. Cuando ejecuté el instalador msi de 64 bits, ya no aparecen advertencias.

Pero los archivos .msi incluidos en el archivo instalador .exe no están actualmente firmados digitalmente. La razón: Son builds nocturnos. En ese momento dejé de investigar. Las compilaciones nocturnas no son para sistemas de usuarios finales. Esperemos, cómo es la versión final de esa herramienta y si tiene las mismas vulnerabilidades señaladas anteriormente.

Post Views: 390
Las cookies ayudan a financiar este blog: Cookie settings
Advertising

Deja una respuesta

Tu dirección de correo electrónico no será publicada.