AUTORUN.INF en WINDOWS: Articulos de Hispasec al respecto

AutoRun en Windows: Se acerca el fin de esta funcionalidad (I)
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. 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.

Fuente

y la segunda parte:
AutoRun en Windows: Se acerca el fin de esta funcionalidad (y II)
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. Repasemos un poco la historia del
Autorun.

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

Comentarios

A ello cabe añadir que, ya en su día, hicimos el ELIPEN para poder eludir dicho problema, pero que debe tenerse en cuenta que la ingenieria social logra en ocasiones engañar al usuario, y hacer que ejecute, sin querer, el malware, que es copiado al pendrive con icono de carpeta, pero ejecutable, y que al pulsar doble click en su icono para “entrar” en la supuesta carpeta, lo que se hace es ejecutar el malware, y asi se ha propagado recientemente un peligroso Rootkit del que ya hemos hablado, el PINKSLIPBOT, pero contra ello solo cabe mentalizar a los usuarios …
saludos

ms, 5-3-2011