Microsoft acaba de publicar como actualización automática el parche que  deshabilita el Autoplay 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.
Ya en noviembre de 2008 publicábamos este artículo en MundoPC.NET para desactivar esta característica, pero repasemos un poco más la historia.

Noticia de 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, 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.

Opina sobre esta noticia:

http://www.hispas...aaldia/4514/comentar

Más información:

Cómo deshabilitar la funcionalidad de la ejecución automática en Windows

http://support.mi...rosoft.com/kb/967715

02/08/2010 Microsoft publica actualización fuera de ciclo para
vulnerabilidad en los .lnk

03/05/2009 Microsoft mejora la “autoejecución” de Windows 7. ¿Gracias, Conficker?

http://www.hispas...ec.com/unaaldia/3844

19/02/2000 Ataques a través del autorun

http://www.hispasec.com/unaaldia/480

27/05/2008 Virus y promiscuidad. Del disquete al USB

http://www.hispas...ec.com/unaaldia/3503

25% Of Malware Spread Via USB Drives

http://www.inform...?articleID=227100125

Sergio de los Santos
ssantos[ssantos arroba hispasec.com]

Entradas relacionadas

1. Deshabilitar la funcionalidad autorun para evitar virus de USB y otros dispositivos extraíbles
2. VIRUS: WIN32/AUTORUN.KS
3. Windows 7 realzará la funcionalidad de las redes sociales
4. Windows 7 no incorporará soporte para USB 3.0
5. Microsoft mejora la “autoejecución” de Windows 7. ¿Gracias, Conficker?

Un comentario para “AutoRun en Windows: Se acerca el fin de esta funcionalidad”