10 Comentarios para “Tecnología en los motores antivirus/antispyware”

1. Zohiartze
   Comment por Zohiartze | 06/06/06 at 6:16 pm

   Yo creo que el tema es bastante sencillo. Por ejemplo hoy leía este articulo de securityfocus:

   http://www.securityfocus.com/columnists/405

   Y este otro que esta relacionado:

   http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf

   Los usuarios no tienen (ni tienen por que tener) criterio relativo a la seguridad a la hora de navegar por internet, descargar archivos, etc… ¿Por que entonces deberían tener un criterio a la hora de elejir productos relativos a la seguridad informática? Yo creo que las empresas hacen lo que tienen que hacer, esto es, ganar dinero. Si a mi me dan dinero por algo que no lo vale, no tengo por que rechazar ese dinero, a no ser que este engañando a viejecitas sin recursos (eso sí sería deplorable). Yo a mis padres, por ejemplo, les tengo instalado el Avast, que al menos dispone versiones gratuitas.

   Me imagino que la inseguridad decrecerá cuando el usuario doméstico no sea el responsable de mantener su propia máquina. Un ejemplo serían aplicaciones web (como parece que poco a poco irá ofreciendo Google) o shells remotas donde sean «expertos» quienes vigilen por la seguridad del usuario domestico. Pero incluso en ese caso ¿quien se fiaria de esos «expertos»?

2. vmalvarez
   Comment por vmalvarez | 06/06/06 at 7:38 pm

   El problema de estos streams alternativos es que están «atrapados» en un sistema de archivos NTFS. No se puede transferir un fichero con sus posibles streams alternativos de un sistema NTFS a otro que no sea NTFS, ni se pueden enviar a través de un e-mail, o de una conexión de red en general, para ello habría que convertirlo primero a un fichero «normal». Por esa razón, salvo algún virus que salió como prueba de concepto, el malware no suele usar esta técnica. Es cierto que los streams alternativos podrían servir para esconder información, pero también podría esconderse información dentro de otro archivo común y corriente, usando técnicas de esteganografía por ejemplo. En cualquier caso, para sacar estos datos de su escondite se necesita otro programa, que tendrá que estar en un fichero normal. Ese es el punto débil de la cadena.
   El ejemplo que ponen en SecuriTeam no es el más feliz, porque si bien es cierto que el malware que meten dentro del stream alternativo no lo detectan muchos antivirus, también es cierto que ese malware no se puede ejecutar sin antes sacarlo a un fichero ordinario, o sin que intervenga un segundo programa.
   Con esto quiero decir que los productos antivirus deberían ser capaces de leer y analizar estos streams alternativos, y estar preparados por si aparece algún malware que los aprovecha, pero que la situación dista mucho de ser grave. Hay otros peligros mayores a los que se puede enfrentar un antivirus, pero es tema para otra ocasión….

3. Lebrel
   Comment por Lebrel | 06/07/06 at 12:33 am

   El asunto de los streams alternativos no deja de ser una técnica que, por ahora, no ha evolucionado más allá de la mera prueba de concepto; es factible, pero como dice victor no se ha logrado integrar de una forma efectiva en ningún malware. Sería demasiado costoso habiendo otras maneras más sencillas.
   El verdadero peligro está, a mi manera de ver, aletargado en forma de otras técnicas esperando a que algún desarrollador las implante de una forma decente en su criatura; es entonces cuando a todos les va n a entrar las prisas. Y para muestra un botón: que es lo que pasó con los rootkits? Porque, y no es por pecar de prepotente, antes de que apareciese el famos rootkit de Sony ya había escrito un documento en el que dejaba bien claro (y con pruebas) que en el momento en que se integrase tecnología rootkit con malware todos los AV se iban a ir a /dev/null; y? ni puto caso. Luego apareció el de Sony y se de uno que se quedó hasta las mil para poder «detenerlo» mediante tecnologías sin prepaprar.
   No se si esto ha sido un cometario o un desahogo, creo que ambos.
   S2

4. mballlano
   Comment por mballlano | 06/07/06 at 3:05 am

   Estoy totalmente de acuerdo con lo que comenta Lebrel, es más, esta noticia no pretende ser sensacionalista ni mucho menos, lo único que quiero decir es que 6 años son suficientes como para implementar esa funcionalidad en el núcleo de un programa de seguridad , quizá esa vulnerabilidad en concreto no sea peligrosa, pero teniendo la seguridad en mente cualquiera habría implementado un mecanismo para evitar problemas futuros … ¿cualquiera?, bueno,,, quizá sí que estoy equivocado…

5. ggonzalez
   Comment por ggonzalez | 06/07/06 at 10:33 pm

   La solucion al problema que plantea mballano, desde mi punto de vista, viene por cambiar de manera radical el modelo de seguridad que los sistemas operativos utilizan. Es decir, como se esta empezando hacer en algunos SOs academicos, implementar la seguridad desde la base, siendo el usuario capaz de controlar los privilegios otorgados a cada proceso e impidiendo que estos puedan da;ar cualaquir otra parte del sistema.

6. inocram
   Comment por inocram | 06/07/06 at 11:21 pm

   Estoy de acuerdo en lo que comenta Victor en lo relacionado con los problemas asociados a los Streams de NTFS en lo que se refiere a su uso por parte de los programadores de virus. Razones a mi modo de ver mas que suficientes como para que los coqueteos del malware con los Streams no pasen de la pura prueba de concepto. Por un lado la limitación autoimpuesta por un malware que utiliza una tecnica basada en cracteristicas exclusivas del sistema de ficheros NTFS. Por otro lado, y relacionado con lo primero, el problema nada desdeñable que se plantea a la hora de intentar propagar un malware con estas caracteristicas. Y podríamos mencionar además, la poca información que existe al respecto.
   Sin lugar a dudas Microsoft no se ha esmerado a la hora de extender el conocimiento y uso de los Streams de NTFS. Y eso se puede ver incluso en sus propios productos. A modo de ejemplo, actualmente la unica opción que da Microsoft para enumerar los Streams de un fichero pasa (que yo sepa) por una llamada directa a ntdll.NtQueryInformationFile, y además con una clase que no está documentada (aunque si está presente en las cabeceras del DDK). Mas escandaloso me parece el hecho de que Windows no tenga en algunos casos en cuenta los Streams, cuando es evidente que son claves en procesos como el control sobre las cuotas de los usuarios, por poner un ejemplo.
   En la nueva versión de Windows Vista ya existirá funcionalidad a nivel de subsistema Win32 para recorrer los streams asociados a un fichero, FindFirstStreamW/FindNext… Por otro lado algunos compresores ya dan desde hace tiempo la posibilidad de comprimir los streams (i.e. WinRar permite almacenar los streams y la información de seguridad asociada al fichero). Desde hace tiempo NTFS es el sistema de ficheros habitual de los usuarios de Windows. Podría decirse que se estan comenzando a dar las condiciones objetivas que pueden permitir el uso «in the wild» de esta técnica para la distribución de programas potencialmente dañinos.
   Lo que está claro es que si hasta la fecha las empresas de seguridad no han prestado atencion a los Streams, por el momento han vivido peligrosamente, pero podríamos decir que no se han equivocado (desde un cierto punto de vista que yo pesonalmente no comparto). ¿Les prestarán atención ahora o quizás tendremos que esperar a que el daño ya esté hecho?

7. mballlano
   Comment por mballlano | 06/07/06 at 11:30 pm

   Al hilo de lo que comenta inocraM sobre el control de cuotas de usuario, es bastante vergonzoso que el propio Windows no lo controle, algún universitario igual se está regocigando mientras lee esto :-).

8. Zohiartze
   Comment por Zohiartze | 06/12/06 at 8:38 am

   Bueno, lunes por la mañanita y parece que esto de los streams va a dar un poco más de que hablar 🙂

   http://blogs.securiteam.com/index.php/archives/438

   Slds.

9. vmalvarez
   Comment por vmalvarez | 06/12/06 at 10:04 pm

   Voy a tener que retractarme y darle toda la razón a mballano ( pero te jodiste, porque en esta no apostamos nada 😛 ) Uno de mis argumentos para decir que el problema de los streams no era tan grave era que no se podía ejecutar directamente el contenido de uno de ellos, pero es completamente falso. Acabo de ver el link de Zohiartze y me dió por comprobar si era verdad eso que comentaban de que en el ImagePath de un servicio de Windows se podía hacer referencia a un stream, y en efecto se puede. Y no solo eso, en un una humilde llamada a CreateProcess se puede poner algo como CreateProcess(«angel.exe:devil», …..) y ejecutar el stream «devil» en vez del stream principal. Luego investigo más el tema, y para la otra investigo antes de hablar 🙂

10. svch0st
    Comment por svch0st | 06/16/06 at 9:05 am

    Esto es otro ejemplo de que solo hay un interés en la mayoría de las empresas que llaman «de seguridad»…. ¿A qué no adivinais cual es?
    Sino, ¿cómo es que no se dedican más recursos a sistemas detectores de rootkits, sistemas sandbox, clasificacion automática de malware y, en definitiva, I+D+i? (contestando a la primera pregunta esta quedaría contestada.)
    Lo único que se vende es el producto de un cigarro.

Se han cerrado los comentarios