martes, enero 19, 2010

Protegerse contra el exploit 1day de IE

Vaya por delante que el 0day famoso que se utilizó en el ataque contra IE6 e IE7 en XP sin DEP ya no es tal 0day. Quizá habría que utilizar la tan traida referencia de 1day, porque ya se conoce mucha información de él.

La diferencia, aunque sutil, marca una enorme distancia. De poco sirve ya que el exploit, por unos más avezados expertos de seguridad, haya sido mutado para funcionar en un entorno con DEP, tal como funciona IE8. Esto es debido a que los administradores y usuarios avanzados tienen la información suficiente para implementar un workaround. Y, por lo tanto, no es necesario cambiar de navegador.

Una vez conocida la información del exploit, se sabe que es condición necesaria el contar con Javascript habilitado. Para evitar por tanto este tipo de ataques, en Internet Explorer, existen las zonas de seguridad. Éstas, en situación de peligro, pueden ser configuradas a necesidad, eligiendo las características que se desean deshabilitar en cada caso.

En una situación conocida de riesgo como ésta, a los administradores de una red Windows que cuenten con IE8 y Active Directory la solución es tan sencilla como aplicar una política que desactive JavaScript de las zonas de Internet y dejarlo habilitado únicamente para los sitios de confianza.

Internet Explorer es una herramienta pensada para trabajar, y para trabajar en las empresas, con lo que es tan sencillo como utilizar la opción adecuada de la política y distribuirla.


Figura 1: Políticas IE en Active Directory

Si no se cuenta con un AD, el usuario siempre puede establecer su propia configuración de seguridad en las herramientas de IE, en la pestaña de Seguridad.


Figura 2: Zonas de seguridad

Se desactivan los códigos script en la zona de Internet inhabilitando cualquier ataque desde un sitio no deseado.


Figura 3: Deshabilitación de código script

¿Esto significa quedarse sin javascript? No, significa que si necesitas javascript y el sitio es de confianza, como aplicaciones internas o sitios en los que se confía, basta con agregarlos a los sitios de confianza. Suena redundante, pero es lo que tiene a veces explicar lo evidente.


Figura 4: Sitios de confianza

Esta forma de trabajar debería hacer pensar de verdad a todos los que están pensando o han pensado en, siguiendo las menos afortunadas recomendaciones, cambiar de navegador. Esto, tal vez hubiera sido una alternativa cuando no se conociera información del fallo, pero nunca cuando se conoce, ya que se puede armar un workaround. La pregunta es... ¿Y si cambias tu empresa a un navegador no administrado con políticas? ¿Y si cambias a un navegador sin zonas de seguridad? ¿Y si cambias a un navegador que no tiene protecciones como el MIC, el Virtual Store, Anti XSS o una separación de procesos? ¿Es esa una buena opción?

He leído información al respecto en muchos sitios, pero me váis a permitir que me quede con el twitter de David Barroso que hizo al respecto hoy por la mañana.


Saludos Malignos!

43 comentarios:

  1. Técnicamente, lo de MrWolf es un re-twitt :-)
    Completamente de acuerdo con lo que se dice a modo de corolario.

    ResponderEliminar
  2. Felicitaciones, una noticia muy útil.

    w3wes@jamon-espana.com.es

    ResponderEliminar
  3. La vulnerabilidad ya no es Zero Day?
    Han sacado ya parche entonces para la vulnerabilidad?
    No he visto nada en mis actualizaciones automáticas.
    Podrías poner el enlace?

    Gracias! :D

    ResponderEliminar
  4. @Anónimo, se llaman exploits de Zero day no vulnerabilidades de Zero day. Deberías saberlo ;)

    La clasificación entre 0day y 1day no es mía, me la enseño un amigo que sabe mucho de esto.

    Saludos!

    ResponderEliminar
  5. Sin contar que, lógicamente, la mayor parte de los antivirus tienen o estan firmando el exploit, el equipo de Spectra protege las redes con GAPA en MS Forefront TMG 2010 y que hay montón de firmas rulando para IDS. Hay una gran diferencia entre 0day y 1day.

    ResponderEliminar
  6. Anónima Buenorra19/1/10 9:09 p. m.

    Chema, ¿Has leído ésto?

    http://www.publico.es/ciencias/286729/alemania/francia/recomiendan/utilizar/explorer

    Me parece acojonante!

    ResponderEliminar
  7. Enhorabuena. Coño un post sobre el tema como Dios manda. Si es que cuando quieres...

    ResponderEliminar
  8. Pues la verdad Chema es que en ésta no te voy a dar la derecha. Administro un dominio con Active Directory, y la verdad me parece una putada deshabilitar el java script. Sobre todo, cuando se tienen usuarios con distintos privilegios de acceso a la red.
    Si ponemos un poco los pies sobre la tierra, me gustaría saber cuantos administradores tienen identificadas la totalidad de las páginas de "confianza" a las cuales acceden los usuarios de las empresas en las que trabajan.Y quien nos garantiza que los servidores de las páginas de "confianza" no hayan sido comprometidos.
    Por supuesto que no por ello vamos a cambiar de navegador.Esa postura definitivamente no la comparto.
    Lo que si espero, es que en vez de buscar soluciones temporales; Microsoft se ponga las pilas y saque de una vez por todas el bendito parche (escuché por ahí, que para el sábado lo liberan).
    Por si alguien no se enteró, el IE8 no está exento por mas que esté activado el DEP, o bien ejecuté en Windows Vista/7/2008
    http://www.vupen.com/english/advisories/2010/0135.

    ResponderEliminar
  9. Buenas,
    Soy admin de mi empresa. Utilizo AD. Si pongo esa política, cada 20 segundos tendría una llamada de un usuario diciendo que no le funciona el internes, que se ve mal una página, que no puede ver bien los periódicos, que no puede entrar en su banco, que no puede...

    Como se me ocurra decirles que vayan añadiendo a sitios de confianza me van a contestar que "... yésto ¿cuándo lo vas a arreglar?"
    Al menos a mis usuarios inténtales explicar que es para evitar exploits 1days que entonces "... yésto ¿cuándo lo vas a arreglar?"

    Me parece una solución eficaz pero no cómoda. Y lo incómodo nunca triunfa.
    Hasta para añadir este comentario he tenido que añadirla a sitios de confianza...¿lo será no?

    Borde

    ResponderEliminar
  10. La gran pega es que sin javascript no funciona casi ninguna página web.

    Y la segunda gran pega es que añadir una web a sitios de confianza implica permitirle más cosas que ejectutar javascript. ¿Qué pasa si los usuarios, siguiendo las instrucciones, añaden todas las webs que no pueden ver a "sitios de confianza"? Pues que igual encima de esta vulnerabilidad se les cuela otra activex o vete a saber qué...

    En fin, que o sacan el parche o sacan el parche.

    ResponderEliminar
  11. Coño Chema Ferrari ¿pero no esperaras que la peña deshabilite el JS para todos los usuarios?...

    Que locura a saber que páginas visita la peña... seguro que si desenchufas el cable de red del servidor también lo evitas.

    Por cierto, ¿para cuando un articulo de pass-the-hass y una explicación del motivo por el cual se permite este tipo de ataques?.

    Besitos del anónimo peluquero ;D

    ResponderEliminar
  12. Saludos,

    primero felicitaciones por el blog y el contenido. Si bien es cierto que uno puede minimizar el riesgo al configurar IE como mencionas, también es cierto que existen variables no controladas por el usuario. Ejemplo, qué pasa si los sitios de confianza han sido comprometidos ?

    ResponderEliminar
  13. Aunque el término exacto sea "exploit Zero Day", yo creo que si la vulnerabilidad no está corregida no podemos dejar de hablar de un "Zero Day", puesto que no sabemos cuantos exploits Zero Day además de este puede haber por ahí, verdad?

    ResponderEliminar
  14. @Anonio que no me da la derecha. El bug es una putada, pero hay que gestionarlo, es nuestro trabajo. No tienes ese problema con las directivas con aD, pq tan bien gestionas los sitios de confianza. En Spectra están trabajando "around the clock" con esto, que ya lo he visto en otra ocasión, pero sacar un parche como este exige muuuuuucho trabajo, que hay muchas aplicaciones que probar. ¿Te parece una putada deshabilitar el javascript en la zona de internet? ¿Como crees que le parece a una empresa que tenga 200 aplicaciones y 20.000 usuarios en todo el mundo cambiar de navegador?

    @Anónimo "borde", sí, es incómoda, pero repito que se pueden gestionar los sitios de confianza dese el aD. Para eso están los equipos de seguridad en las empresas y la seguridad gestionada, etc... Siento haberte parecido borde, no era mi intención.

    @Anonimo, 1:17 AM. Es cierto que javascript se necesita para muchas cosas, hasta para lanzar un exploit como este. Es incómodo, pero no es cierto que sea estrictamente necesario para todo. Entiendo que esta solución para el home user poco técnico es una mala decisión, pero para la empresa es una solución muy efectiva. ¿Cómo lo harías en una situación similar con otro navegador?

    @anónimo "peluquero". ¿Lo del pass the hass lo quieres en Windows o tb quieres algo similar con "otros sistemas operativos"?

    @anónimo mutaciones, por supuesto que hay mutaciones, pero por eso se firman las vulnerabilidades además de los exploits. Microsoft tiene una tecnología que se llama GAPA y un lenguaje GAPAL para firmar vulnerabilidades. Una vez conocida como se explota la vulnerabilidad se buscan patrones y se firman.

    @OpenSec, sí, por eso la seguridad en las empresas debe estar gestionada por los responsables de seguridad y contar con una herramienta como el navegador gestionable desde el AD es mmmmmmmmmmmuyyyyyyyyyyyyyyy bueno.

    ResponderEliminar
  15. ¿Seria una medida de seguridad virtualizar un nuevo XP en la maquina del usuario para usar el navegador con javascript habilitado?

    ResponderEliminar
  16. Peeerooo... y si resulta que no estamos en una empresa con AD sino en casita?? No acaba de convencerme la cosa...

    ResponderEliminar
  17. @Anonimo como alternativa doméstica siempre se puede usar lynx o w3m para los más sibaritas.

    ResponderEliminar
  18. ¡Pero Chema! ¿Cómo puedes proponer una medida como desactivar JS? ¡Uf!

    Respecto al argumento de la facilidad de gestión del AD... ya puestos... que se instale el Chrome (o cualquier otro navegador alternativo a IE) en todos los puestos vía políticas/scripts de inicio o similar.

    Ahora en serio, es precisamente en casos como este en los que un IDS/AV/Proxy se seguridad web puede servir para algo (lo que tú llamas 1-day) :) Nada de medidas poco/nada realistas, como la de desactivar JS, hombre :PPPP

    :*
    -r

    ResponderEliminar
  19. @RoMaNSoFt, ¿poco realistas? Es la que recomiendan los que han hecho el exploit.

    Por cierto... scripts de incio? La gente se queja por usar las zonas, arreglarlo con scripts de inicio para Chrome será divertido verlo... ;)

    De hecho, podéis contratar a I64 para que os hagamos el script....Ya sabes.. ;)

    ResponderEliminar
  20. @maligno: ¿te refieres a quien hizo el exploit de verdad? ¿O a los que lo han utilizado/adaptado/cazado/publicado? Vamos, que una recomendación así podría haber salido de cualquier parte. Entre otras cosas, porque es perfectamente válida (desde el punto de vista de mitigación de la vulnerabilidad). Pero que mitigue la vulnerabilidad no quiere decir que sea práctico. También he visto en muchos exploits recomendaciones como: "no usar este producto". Efectivamente, "mitigan" la vulnerabilidad }:-) Y como lo dice el autor del exploit... habrá que hacerle caso, ¿no? :P

    La moraleja de todo esto es que IE puede ser tan vulnerable como cualquier otro navegador (por muchas "protecciones" que traiga el IE8, y que de hecho, ya las tienen otros navegadores -p.ej el antiXSS de IE8 va por detrás del NoScript de Firefox-, o las acabarán teniendo a corto/medio plazo).

    No hay que ser talibán :-P

    ResponderEliminar
  21. @RoMaNSoFt, el NOScript no viene en mi Firefox. ¿Es un plugin o algo así? ¿Hay para FF un Apolo como el que tengo yo para IE? ¿Lo contamos también?

    Hay quedan los resultados de BrowserSchools...

    Las zonas de IE te dan una solución. ¿Qué te daría otro navegador con las opciones que trae por defecto? ¿Cuantos plugins extras necesitas desplegar tb? ¿Necesitas a i64 para hacerte un script?

    }:)

    ResponderEliminar
  22. ¡Pero bueno!, ¿realmente estás proponiendo que la forma de librarse del problema es crear una lista blanca de sitios donde el javascript esté permitido?, ¿Te estás riendo de la gente o qué pasa?, en primer lugar, este error es culpa de microsoft y por lo tanto es microsoft la que debería haber publicado ya un parche, que para eso es su trabajo. Y en segundo lugar, esto de deshabilitar el javascript en todos los sitios por si acaso no son de confianza... supongo que te refieres a empresas de 5 trabajadores, porque si no te invito a que te pongas tu a hacerlo, machote.

    Además que deshabilitando el javascript seguro que te libras de muchos problemas, no solo de este, pero se supone que es matar moscas a cañonazos, no una solucion viable en un entorno laboral.

    Y encima dices que esta sencilla solución evita que tengas que cambiar de navegador, no me jodas, esta sencilla solucion invita a cambiar de navegador, y no esta semana, si no para siempre.

    ResponderEliminar
  23. uuf no os pegueis niños! xD

    No tengo un firefox aquí para comprobar, pero creo recordar que en el about:config había una opcion de crearte listas seguras bajo una de las claves security."algo"

    Es evidente Chema que no es solución desactivar JS, que no haya mejor solución de momento puede, pero eso no es objetivamente realista en ninguna empresa, y a mi te aseguro que no me van a volver loco en el curro porque las de rrhh no puedan ver el Vogue digital por ejemplo xDD

    Y recordar que firefox también puede (o podía, no lo sé) aprovecharse de la config de zonas de seguridad establecidas en windows (a traves de IE pero algo es algo)buscad el post de S. de los Santos hace algún tiempo..

    Fallos los tienen todos, o de eso vivimos al menos, y que sigan saliendo!! :P

    Saludos!

    Wi®

    ResponderEliminar
  24. Chema, ahora aclará eso del Apolo para IE.

    ResponderEliminar
  25. Ahí va!, esto SÍ es un 0day ;D.

    http://lists.grok.org.uk/pipermail/full-disclosure/2010-January/072549.html

    ResponderEliminar
  26. Maligno,
    solo aclarar que no te llamaba borde.

    Es que yo suelo firmar como Borde porque a mi sí me consideran tal

    --yo no quería hacer spam--
    elbordeinformatico.wordpress.com
    --basta ya de spam--

    Saludos y enhorabuena por tu trabajo que es muy bueno.

    ResponderEliminar
  27. Hola

    Bueno después del Up to secure me ha quedado más claro, que no es un 0day realmente

    Un saludo

    ResponderEliminar
  28. Poner listas blancas temporalmente para uso de javascript es mucho mejor que migrar la plataforma de navegador. Y la buena noticia es que se puede hacer fácilmente con el AD. Sigo preguntando ... Si esto pasa en el futuro con otro navegador.. ¿cómo lo vas a hacer?

    @extremitu, sí, una elevación en local y con el workaround publicado. ¿Sigues las listas de elevaciones de privilegios locales en otros sistemas operativos?

    Saludos!

    PS: Apolo es un plugin BHO nuestro para identificar el correo ilegítimo en Gmail y Hotmail que sólo funciona en IE8. ;)

    ResponderEliminar
  29. @Maligno desde el máximo respeto que tengo por alguien que tiene que ponerme nota, me parece que los resultados de BrowserSchools son aplicables sobre navegadores con configuración por defecto. La manera en la que está planteado el reto puede llevar a pensar en una sutil manipulación para llegar a unos resultados que "realcen" las bondades de IE frente a firefox y resto de navegadores que usamos la gente sin recursos económicos suficientes para permitirnos so de pago.

    citando a un tal RoMaNSoFt
    No hay que ser talibán :-P

    ResponderEliminar
  30. Como administrador es más fácil, y para el usuario le de más libertad, instalar un puto enlace a un Firefox Portable configurado. Cero instalación e infinita seguridad más que IE.

    Y como sé que lo vas a preguntar, si la cosa fuera igual con otro navegador, lo haría también. Versión portable de la competencia y santas pascuas.

    Debo ser de otro planeta, porque la solución no te convencerá ni a ti ni a los freetalibanes, pero en cuestión de comodidad de administración y de no caparle a los usuarios lo que no se debe, es imbatible.

    PD: Microsoft "acelera" su parche mensual pero A DÍA DE HOY NO HAY NI FECHA.
    http://www.elpais.com/articulo/tecnologia/Microsoft/publicara/parche/extraordinario/Internet/Explorer/elpeputec/20100120elpeputec_4/Tes

    ResponderEliminar
  31. Completo por olvido: Me refería a acceso al Firefox Portable hasta que esté el parche del IE disponible; cuando esté, vuelta al IE.

    ResponderEliminar
  32. Gracias a Dios que no se me ocurre usar Ie, ninguna version, aqui hay demasiado microsoftismo me parece a mi... jeje desactivar JS?? jajaja como decia alguien por aqui mejor quitar el cable y apagar el Pc asi no hay problemas.....

    ResponderEliminar
  33. El peluquero:

    Chema el Pass-the-Hash de los windows molones y claro está, si me pones ejemplos de otros sistemas operativos pues mejor que mejor, pero cúrratelo no me hagas un trolentrada de las últimas...

    A mi me encanta en las auditorias cuando obtengo la hash de una máquina y me permite conectarme a otras máquinas no vulnerables sin necesidad de petar el hash, le enchufo el hash a la memoria y OLÉ! ¿por que implementar correctamente un reto? eso paque!...

    Por cierto chema estoy ansioso de ver tu post defensa a una vulnerabilidad reportada en verano y casi en febrero sea un 0-day.

    Un saludo informática16 (bits por supuesto) :P

    ResponderEliminar
  34. @David, una emperesa que tenga 200 aplicaciones desarrolladas en web... ¿les cambias el soporte a FF? ¿Y si las app usan ActiveX? La solución de cambiar el navegador tiene un impacto en el negocio demasiado alto en organizaciones medianas o grandes.

    @Anónimo, mira esta noticia de seguridad sobre un 0day de FF en el que se recomienda desde "otros que tb saben algo de seguridad"..

    http://www.hispasec.com/unaaldia/3917/ejecucion-codigo-mozilla-firefox-existe-parche-ofic

    Te la copio entera, que es muy chula:

    " Ejecución de código en Mozilla Firefox. No existe parche oficial disponible
    Ofrecemos este boletín con carácter de urgencia. Se ha publicado un exploit para Mozila Firefox 3.5 que permite la ejecución de código si un usuario visita una página web especialmente manipulada. No existe parche oficial disponible.

    Un tal Simon Berry-Byrne ha descubierto un problema de seguridad en Firefox que podría ser aprovechado por atacantes para ejecutar código arbitrario con los privilegios bajo los que se ejecuta el navegador. Existe exploit público disponible, con lo que es posible que los atacantes comiencen, en breve, a explotar el fallo para la instalación de malware, y "aprovechar" así la creciente cuota de mercado de usuarios de Firefox.

    El exploit ha sido publicado sin previo aviso, con todo lujo de detalles y listo para ser usado en entornos Windows. Aunque no es necesario una excesiva modificación para que pueda ejecutarse código en cualquier otra plataforma. El fallo en concreto se da en (cómo no) el procesador de código JavaScript del navegador a la hora de manejar ciertas etiquetas ("font", entre ellas) HTML.

    No se tiene constancia de que los atacantes estén aprovechando este fallo, por lo que no se podría hablar estrictamente de "0 day", aunque a partir de ahora el problema es grave, puesto que el código para su explotación es público.

    Se recomienda desactivar JavaScript en Firefox o el uso de navegadores alternativos (no Internet Explorer puesto que en estos momentos también sufre de varios problemas de seguridad no resueltos)."

    @Anónimo peluquero, las elevaciones locales no tienen tanto glamour. De pass the hass tengo aquí un artículo escrito de 15 páginas que estoy dandole la vuelta para ver si lo publico o no. En tus auditorias de seguridad con XPs mal administrados y con cacheo de credenciales tal vez funcione muy bien en la red pero si usan una buena política en AD no.

    Si tienes acceso local en un linux te recomiendo que juegues con Kon-boot o que hagas uso de alguno de los ene-cientos bugs de elevación local en linux que ha habido este año. Ya no les hago ni chistes..

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

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

    Ya no son tan graciosos como antes... Pero me alegra que te haga ilusión uno en Windows que se arregla con una policy.

    Saludos melenas!

    ResponderEliminar
  35. A ver chemita... la solucion de desactivar javascript (o hacer una lista blanca de javascript)... ja! y otra vez ja!, me permitiras decir que es UNA PORQUERIA y un sin sentido en esta epoca de web 2.0

    ResponderEliminar
  36. @maligno Tanto que te molan los workarounds y tunear la instalacion por defecto... Y ya que hablas inderectamente de los fallos de linux... Con tal de meter un mmap_min_addr mayor que 4096 (que casi todas las distros ya empiezan a meter por defecto...), dime cuantos de esos fallos de elevacion de privilegios quedan que han publicado el año pasado...

    ResponderEliminar
  37. @dreyercito, ya tienes tu parche de IE8. ¿Qué es mejor, hacer la lista blanca de JS como recomendaba Hispasec para el fallo de FF y yo para IE8 o haber empezado una migración del navegador en una empresa?

    Seamos serios...

    Hay que buscar la mejor solución. Todos, incluidos los que odian a Spectra, sabíamos que MS iba a sacar el parche pronto. Como lo ha hecho. Recomendar la migración era de ....

    Saludos!

    ResponderEliminar
  38. http://www.sahw.com/wp/ que sepas que el DEP no sirve para nada, bien explicado por SH. Y..por cierto no queremos soluciones de medio pelo, queremos el Parche que ya de por si no deja de ser...pues eso UN PARCHE. Para los mas técnicos corrección de una parte del código vulnerable a un ataque remoto o local.

    ResponderEliminar
  39. @xeno, cuando pusiste tu comentario el parche ya estaba sacado. Tal vez no te diste cuenta pq nunca usas IE8. Tal vez ni tengas el Windows original, pero no te preocupes, que con Sergio también hablé antes de que pusieras este comentario. Le dejé mi opinión en su post.

    Saludos!

    ResponderEliminar
  40. http://limulus.wordpress.com/2010/01/20/microsoft-lies-to-your-face-about-browser-security/

    ResponderEliminar
  41. Y sigue la fiesta!
    http://www.reuters.com/article/idUSTRE60L5O820100122?type=technologyNews

    ResponderEliminar
  42. Maligno said:
    "@David, una emperesa que tenga 200 aplicaciones desarrolladas en web... ¿les cambias el soporte a FF? ¿Y si las app usan ActiveX?"

    Sí, claro, por tanto por tu propio argumento, mucho mejor dejar a todas tus aplicaciones sin Javascript que sin ActiveX. Buf.

    Hablas de una empresa que tenga 200 aplicaciones desarrolladas en web. Si están desarrolladas en web, y hablamos de una empresa grande (¿hablas de una empresa grande verdad?), hay estándares de codificación, guías de estilo, normas de compatibilidad... que impiden o como mínimo desaconsejan a Desarrollo el pase a Explotación/Producción de aplicaciones IE (que no aplicaciones WEB), o que usen ActiveX. Por no hablar de aplicaciones de cara al exterior y no en la Intranet.
    Por supuesto que hay excepciones, pero son eso, excepciones (por ejemplo, en mi época era absolutamente necesario usar Explorer con Test Director/Winrunner para generar y ejecutar planes de prueba, sólo admitía ActiveX).

    En resumen. En "todas esas empresas grandes" el impacto al negocio de no usar Javascript es infinitamente mayor al de no usar ActiveX.

    "La solución de cambiar el navegador tiene un impacto en el negocio demasiado alto en organizaciones medianas o grandes".
    Por supuesto, mi idea hay que desarrollarla. Porque busca minimizar esto, es una mínima aproximación inicial, implantable perfectamente en muchas PYMES (más 'P' que 'M', claro).
    La de usar durante días un navegador con exploit tiene un impacto infinitamente mayor, en especial en determinados sectores como el bancario o el hospitalario. El problema, Chema, como bien sabes, es que para los usuarios, mandos intermedios y directivos, la seguridad es mucho menos problema que cambiar, aunque sea ínfimamente, su forma de trabajar.

    ResponderEliminar
  43. @David, no tienes que quedarte sin Javascript, tienes que quedarte sin Javascript en los sitios que no son de confianza....

    Y, por supuestísimo, para todas las aplicaciones que han usado ActiveX (¿te paso una lista?) lo del javascript es una chorrada.

    Me encanta que te guste el párrafo de los estándares ;)

    ResponderEliminar