Microsoft acaba de publicar como actualización automática el parche que deshabilita el Autoplay (KB971029) en dispositivos USB en todos sus Windows (solo la versión 7 lo hacía correctamente por defecto hasta ahora). Con este movimiento, da (por fin) el paso final para aniquilar una funcionalidad que ha traído muchos problemas. Repasemos un poco la historia del Autorun.
Aunque Windows 9x disponía de AutoRun, era una especie de sistema primitivo que no podía ser comparado con el de XP. Además, por aquel entonces los dispositivos de almacenamiento USB no eran demasiado populares, mientras que los disquetes todavía se usaban. Por tanto, se puede decir que el verdadero problema comenzó a finales de 2001, con XP y su Autorun y Autoplay. Distingamos entre estos dos conceptos.
Autorun y Autoplay
Autorun: Es la capacidad del sistema operativo (no solo de Windows) de ejecutar dispositivos extraíbles cuando son insertados en el sistema. En Windows, los parámetros de la "autoejecución" se definen en un archivo de texto llamado autorun.inf, que aparece en la raíz de la unidad que se inserta.
Autoplay: Es la funcionalidad propia introducida en XP. Complementa y se basa en Autorun. Analiza el dispositivo que se inserta y según el tipo de archivo que encuentre, lanza un diálogo en el que se sugieren las mejores aplicaciones para reproducirlos. Si se elige una acción por defecto, el usuario no necesitará más este diálogo y el programa elegido se lanzará automáticamente la próxima vez gracias a Autorun y la "memoria" de Autoplay.
Hitos importantes
Ya en febrero de 2000, publicábamos en Hispasec un boletín titulado "Ataques a través del autorun". La funcionalidad se presentaba como el sustituto perfecto de la ejecución automática en disquetes pero aplicada a CDs y memorias USB.
Hacia 2005, las memorias USB se popularizaron y comenzaron a aparecer cada vez más muestras de malware que se propagaban por este medio. Hasta el punto de que, a mediados de 2010, ya se calculaba que un 25% del malware se esparcía a través de estos dispositivos.
Pero Microsoft no vio el problema hasta 2008. Se podía deshabilitar esta capacidad a través de políticas o cambios en manuales en el registro y, por tanto, no consideraba necesario cambiar su postura: Windows lo ofrecía como funcionalidad activa por defecto (como tantas otras facilidades) y quien quisiera protegerse, que lo desactivara. Pero esto no era del todo cierto: incluso desactivado, nunca se estuvo verdaderamente protegido. A partir de ahí comienza un recorrido para su desactivación y mejora que, a trancas y barrancas, se aplica ya automáticamente a todos sus sistemas operativos.
En mayo de 2008, en un boletín de una-al-día llamado "Virus y promiscuidad. Del disquete al USB", ya se recomendaba configurar específicamente Windows para ignorar los archivos autorun.inf y atajar el problema de raíz, puesto que ya se conocían formas de eludir la protección "oficial", que consistía en la modificación de la directiva de registro NoDriveTypeAutorun.
Dos vulnerabilidades, un mismo problema
En julio de 2008, Microsoft publicó el boletín MS08-038 que, entre otros asuntos, corregía este comportamiento fallido de Autorun (CVE-2008-0951). Pero solo se ofrecía a través de Windows Update (obligatoriamente) para Windows Vista y 2008. Los usuarios de XP disponían del parche para solucionar el fallo (KB953252), pero había que ir a descargarlo e instalarlo expresamente. No se instalaba automáticamente como el resto de parches de seguridad porque Microsoft tenía miedo de "romper" demasiadas funcionalidades para su (todavía) amplio parque de usuarios de Windows XP. Además, de paso, daba un empujoncito para incentivar la actualización a su sistema operativo más moderno hasta la fecha.
Pero a finales de 2008 apareció Conficker, un malware bastante sofisticado con algunas funcionalidades sorprendentes. Aprovechaba de manera inédita hasta la fecha la funcionalidad Autorun. Creaba un archivo autorun.ini funcional pero disimulado con basura, que conseguía pasar desapercibido para los antivirus. Es decir: los métodos oficiales (a través de la política NoDriveTypeAutorun del registro) recomendados hasta la fecha para evitar la ejecución, seguían sin funcionar realmente. Debido al éxito de Conficker en XP, en febrero de 2009 tuvieron que corregir un nuevo fallo (CVE-2009-0243) a través de una actualización que cubría en parte la anterior vulnerabilidad y que esta vez, era obligatoria para todos. Aunque el parche KB967715 para XP se distribuyó automáticamente a través de Windows Update en esa fecha, sorprendentemente no fue considerado como "parche de seguridad" (no tiene un boletín de Microsoft asociado).
Además, el parche modificaba el comportamiento de Autorun: Después de aplicarlo, se añadía una nueva etiqueta en el registro que debía ser correctamente configurada. En la práctica, para usuarios poco avanzados, Autorun seguía siendo un problema.
Mejoras, pero solo para Windows 7
Después de tanta vulnerabilidad, en mayo de 2009 Microsoft decide mejorar la seguridad de la funcionalidad de "autoejecución" de los medios extraíbles en los que se pueda escribir, evitando el diálogo de ejecución automática (Autoplay) en memorias USB. Lo hacía por defecto en Windows 7 y, para las versiones anteriores de Windows publica en agosto de 2009 el parche KB971029. Una vez más, no era obligatorio, había que descargarlo manualmente. Otro supuesto empujón para motivar el cambio de sistema operativo. Ha sido necesario esperar año y medio para que ahora, a finales de febrero de 2011, se instale de forma obligatoria para todos los sistemas operativos anteriores a Windows 7 desde Windows Update.
Otros problemas con Autorun
Pero aún quedaban dolores de cabeza con la autoejecución. En julio de 2010 VirusBlokAda descubre Stuxnet. El troyano puede propagarse a través de memorias USB prescindiendo del tradicional archivo autorun.inf. Utiliza una vulnerabilidad en archivos .LNK que permitía la ejecución de código aunque el AutoPlay y AutoRun se encontrasen desactivados. A efectos prácticos, implica que se había descubierto una nueva forma totalmente nueva de ejecutar código en Windows cuando se insertaba un dispositivo extraíble, independientemente de que se hubiesen tomado todas las medidas oportunas conocidas hasta el momento para impedirlo. Fuera del ciclo habitual, Microsoft publicó MS10-046 en agosto para solucionar la vulnerabilidad.
En resumen, un largo recorrido hasta hoy: vulnerabilidades que no son corregidas en todos los sistemas, parches de seguridad que no se califican como tal según qué versiones, mejoras que no se ofrecen de forma obligatoria, parches que se superponen a otros parches y parches que modifican la funcionalidad... todo un quebradero de cabeza que parece toca a su fin, con los parches que bloquean y mejoran Autorun y Autoplay difundidos de forma masiva.
Aun así, aún existe una funcionalidad por defecto que impide dar por aniquilado por completo el Autorun: Para los dispositivos que en los que se supone no se puede escribir (medios ópticos), Windows todavía lanza AutoPlay y sigue preguntando al usuario qué hacer. Entre esas opciones permite la ejecución automática.
Fuente: Hispasec
Aunque Windows 9x disponía de AutoRun, era una especie de sistema primitivo que no podía ser comparado con el de XP. Además, por aquel entonces los dispositivos de almacenamiento USB no eran demasiado populares, mientras que los disquetes todavía se usaban. Por tanto, se puede decir que el verdadero problema comenzó a finales de 2001, con XP y su Autorun y Autoplay. Distingamos entre estos dos conceptos.
Autorun y Autoplay
Autorun: Es la capacidad del sistema operativo (no solo de Windows) de ejecutar dispositivos extraíbles cuando son insertados en el sistema. En Windows, los parámetros de la "autoejecución" se definen en un archivo de texto llamado autorun.inf, que aparece en la raíz de la unidad que se inserta.
Autoplay: Es la funcionalidad propia introducida en XP. Complementa y se basa en Autorun. Analiza el dispositivo que se inserta y según el tipo de archivo que encuentre, lanza un diálogo en el que se sugieren las mejores aplicaciones para reproducirlos. Si se elige una acción por defecto, el usuario no necesitará más este diálogo y el programa elegido se lanzará automáticamente la próxima vez gracias a Autorun y la "memoria" de Autoplay.
Hitos importantes
Ya en febrero de 2000, publicábamos en Hispasec un boletín titulado "Ataques a través del autorun". La funcionalidad se presentaba como el sustituto perfecto de la ejecución automática en disquetes pero aplicada a CDs y memorias USB.
Hacia 2005, las memorias USB se popularizaron y comenzaron a aparecer cada vez más muestras de malware que se propagaban por este medio. Hasta el punto de que, a mediados de 2010, ya se calculaba que un 25% del malware se esparcía a través de estos dispositivos.
Pero Microsoft no vio el problema hasta 2008. Se podía deshabilitar esta capacidad a través de políticas o cambios en manuales en el registro y, por tanto, no consideraba necesario cambiar su postura: Windows lo ofrecía como funcionalidad activa por defecto (como tantas otras facilidades) y quien quisiera protegerse, que lo desactivara. Pero esto no era del todo cierto: incluso desactivado, nunca se estuvo verdaderamente protegido. A partir de ahí comienza un recorrido para su desactivación y mejora que, a trancas y barrancas, se aplica ya automáticamente a todos sus sistemas operativos.
En mayo de 2008, en un boletín de una-al-día llamado "Virus y promiscuidad. Del disquete al USB", ya se recomendaba configurar específicamente Windows para ignorar los archivos autorun.inf y atajar el problema de raíz, puesto que ya se conocían formas de eludir la protección "oficial", que consistía en la modificación de la directiva de registro NoDriveTypeAutorun.
Dos vulnerabilidades, un mismo problema
En julio de 2008, Microsoft publicó el boletín MS08-038 que, entre otros asuntos, corregía este comportamiento fallido de Autorun (CVE-2008-0951). Pero solo se ofrecía a través de Windows Update (obligatoriamente) para Windows Vista y 2008. Los usuarios de XP disponían del parche para solucionar el fallo (KB953252), pero había que ir a descargarlo e instalarlo expresamente. No se instalaba automáticamente como el resto de parches de seguridad porque Microsoft tenía miedo de "romper" demasiadas funcionalidades para su (todavía) amplio parque de usuarios de Windows XP. Además, de paso, daba un empujoncito para incentivar la actualización a su sistema operativo más moderno hasta la fecha.
Pero a finales de 2008 apareció Conficker, un malware bastante sofisticado con algunas funcionalidades sorprendentes. Aprovechaba de manera inédita hasta la fecha la funcionalidad Autorun. Creaba un archivo autorun.ini funcional pero disimulado con basura, que conseguía pasar desapercibido para los antivirus. Es decir: los métodos oficiales (a través de la política NoDriveTypeAutorun del registro) recomendados hasta la fecha para evitar la ejecución, seguían sin funcionar realmente. Debido al éxito de Conficker en XP, en febrero de 2009 tuvieron que corregir un nuevo fallo (CVE-2009-0243) a través de una actualización que cubría en parte la anterior vulnerabilidad y que esta vez, era obligatoria para todos. Aunque el parche KB967715 para XP se distribuyó automáticamente a través de Windows Update en esa fecha, sorprendentemente no fue considerado como "parche de seguridad" (no tiene un boletín de Microsoft asociado).
Además, el parche modificaba el comportamiento de Autorun: Después de aplicarlo, se añadía una nueva etiqueta en el registro que debía ser correctamente configurada. En la práctica, para usuarios poco avanzados, Autorun seguía siendo un problema.
Mejoras, pero solo para Windows 7
Después de tanta vulnerabilidad, en mayo de 2009 Microsoft decide mejorar la seguridad de la funcionalidad de "autoejecución" de los medios extraíbles en los que se pueda escribir, evitando el diálogo de ejecución automática (Autoplay) en memorias USB. Lo hacía por defecto en Windows 7 y, para las versiones anteriores de Windows publica en agosto de 2009 el parche KB971029. Una vez más, no era obligatorio, había que descargarlo manualmente. Otro supuesto empujón para motivar el cambio de sistema operativo. Ha sido necesario esperar año y medio para que ahora, a finales de febrero de 2011, se instale de forma obligatoria para todos los sistemas operativos anteriores a Windows 7 desde Windows Update.
Otros problemas con Autorun
Pero aún quedaban dolores de cabeza con la autoejecución. En julio de 2010 VirusBlokAda descubre Stuxnet. El troyano puede propagarse a través de memorias USB prescindiendo del tradicional archivo autorun.inf. Utiliza una vulnerabilidad en archivos .LNK que permitía la ejecución de código aunque el AutoPlay y AutoRun se encontrasen desactivados. A efectos prácticos, implica que se había descubierto una nueva forma totalmente nueva de ejecutar código en Windows cuando se insertaba un dispositivo extraíble, independientemente de que se hubiesen tomado todas las medidas oportunas conocidas hasta el momento para impedirlo. Fuera del ciclo habitual, Microsoft publicó MS10-046 en agosto para solucionar la vulnerabilidad.
En resumen, un largo recorrido hasta hoy: vulnerabilidades que no son corregidas en todos los sistemas, parches de seguridad que no se califican como tal según qué versiones, mejoras que no se ofrecen de forma obligatoria, parches que se superponen a otros parches y parches que modifican la funcionalidad... todo un quebradero de cabeza que parece toca a su fin, con los parches que bloquean y mejoran Autorun y Autoplay difundidos de forma masiva.
Aun así, aún existe una funcionalidad por defecto que impide dar por aniquilado por completo el Autorun: Para los dispositivos que en los que se supone no se puede escribir (medios ópticos), Windows todavía lanza AutoPlay y sigue preguntando al usuario qué hacer. Entre esas opciones permite la ejecución automática.
Fuente: Hispasec
No hay comentarios:
Publicar un comentario