viernes, 31 de agosto de 2007

De nuevo, ejecución de código arbitrario en Yahoo! Messenger

Se ha encontrado otra vulnerabilidad en Yahoo! Messenger que puede ser aprovechada por atacantes para ejecutar código en el sistema víctima. Esta es la tercera vulnerabilidad grave que afecta a este programa de mensajería en solo dos meses. Microsoft Messenger, por su parte, también es vulnerable a un grave problema.

iDefense alertaba de nuevo de un fallo en el programa de mensajería instantánea de Yahoo!. El problema se debe a un error de límites en dos funciones del control ActiveX YverInfo.dll y puede ser aprovechado para provocar un desbordamiento de memoria intermedia si un usuario visita una página web especialmente manipulada. La vulnerabilidad permite la ejecución de código arbitrario, pero para que tenga éxito, la página que aproveche el error debe encontrarse bajo el dominio yahoo.com (o hacer creer a la víctima que se encuentra en él...).

Con este son tres los problemas graves resueltos por Yahoo! Messenger 8.x en los últimos dos meses. A primeros de junio se anunciaba sin duda la que hasta ahora es la vulnerabilidad más grave descubierta en el programa. Permitía ejecución de código con sólo visitar una página web con Internet Explorer (esta vez bajo cualquier dominio) y se publicó un exploit funcional cuando todavía no existía parche.

Hace solo dos semanas, se anunciaba otro problema grave en Yahoo! Messenger que permitía ejecución de código. En este caso el atacante debía enviar una invitación de cámara web y la víctima aceptarla. Este fallo, descubierto por investigadores chinos, se trasladó hasta las versiones 7.x del programa de mensajería instantánea de Microsoft, y resultó (por otras vías) vulnerable a un error parecido en la funcionalidad de webcam. Microsoft no se ha pronunciado todavía al respecto.

Malos tiempos, sin duda, para los programas de mensajería instantánea.

Para este último fallo en Yahoo!, la versión de la librería afectada es la 2007.8.27.1, incluida en todas las versiones de Yahoo! descargadas antes del día 29 de agosto. Se recomienda actualizar lo antes posible a la última versión desde http://messenger.yahoo.com/download.php


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

Yahoo Messenger YVerInfo.dll ActiveX Multiple Remote Buffer Overflow
Vulnerabilities
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=591

28/08/2007 Vulnerabilidad en función webcam de Microsoft Messenger 7.x
http://www.hispasec.com/unaaldia/3230

17/08/2007 Vulnerabilidad crítica en Yahoo! Messenger
http://www.hispasec.com/unaaldia/3219

11/06/2007 Grave vulnerabilidad en Yahoo! Messenger (y prueba de concepto)
http://www.hispasec.com/unaaldia/3152

jueves, 30 de agosto de 2007

Vulnerabilidades en Cisco CallManager y Cisco Unified Communications Manager

Se ha descubierto una vulnerabilidad en Cisco CallManager y Unified Communications Manager que podría ser aprovechada por un atacante para realizar ataques por cross site scripting e inyectar código SQL.

Esta vulnerabilidad se debe a un fallo en la variable lang de las páginas de inicio de sesión de admin y user. Un atacante podría aprovechar esto para ejecutar código JavaScript en el navegador de los sistemas que accedieran a Cisco CallManager y Unified Communications Manager.

Se ven afectadas las versiones Cisco CallManager 3.3, Cisco CallManager 4.x y Cisco Unified Communications Manager 4.x.

Cisco, a través de los canales habituales, ha puesto a disposición de sus clientes software para solucionar el problema.

Se aconseja consultar la tabla de versiones vulnerables y contramedidas en:
http://www.cisco.com/warp/public/707/cisco-sa-20070829-ccm.shtml


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

Cisco Security Advisory: XSS and SQL Injection in Cisco CallManager/Unified Communications Manager Logon Page
http://www.cisco.com/warp/public/707/cisco-sa-20070829-ccm.shtml

miércoles, 29 de agosto de 2007

Troyanos "simples": "Keep it simple, stupid!"

Llevamos meses y meses hablando de lo sofisticado de las técnicas de
los nuevos troyanos, de lo sutil y avanzado de sus métodos, siempre
enfocados a pasar desapercibidos, engañar a usuarios cada vez más
concienciados y entorpecer su propio análisis. ¿Evita eso que exista
una corriente de "involución" en el mundo de los troyanos? Ni mucho
menos. Técnicas simples (incluso chapuceras) siguen obversándose y no
por ello con un menor "éxito" para el atacante. "¡Hazlo simple,
idiota!" (conocida técnica KISS).

Ya se habló en el blog de Hispasec
(http://blog.hispasec.com/laboratorio/) de troyanos sencillos que
pasaban desapercibidos para (en aquel momento) la totalidad de los
motores antivirus con los que trabaja VirusTotal.com (“Cuando 30
antivirus no son suficientes” se llamó la entrada). Hoy vemos como
esta técnica sigue teniendo éxito con numerosas campañas.

La última de las campañas lanzadas corresponde a un supuesto correo
proveniente de la rimbombante "Dirección General de Servicios de
Cómputo Académico de la Universidad Nacional Autónoma de México a
través del Departamento de Seguridad en Cómputo y UNAM-CERT". En un
correo donde precisamente (y con fina ironía) se dan consejos útiles
y reales para prevenir el phishing. El el mensaje se pide la descarga
de un manual.exe que supuestamente contiene más información para
prevenir este tipo de estafas.

Manual.exe está alojado en un servidor legítimo comprometido,
perteneciente a una organización sin ánimo de lucro con dominio .au
(Australia) y resulta ser de lo más chapucero. Sin ningún tipo de
ocultación ni ofuscación de código (de hecho, si se usan técnicas
habituales de ofuscación comienza a ser detectado por los motores
gracias a una herústica paranoide), modifica el archivo "hosts" del
sistema (pharming local) redirigiendo al usuario que pretenda
conectarse a un importante banco mexicano hacia una web fraudulenta
que simula ser la banca online de la entidad.

Un simple vistazo al código desnudo del archivo (abriéndolo con
cualquier editor de texto) permite conocer qué y cómo modifica el
sistema. Es tan "simple" que ni siquiera utiliza la variable de
entorno %systemroot% para encontrar el archivo de "hosts" (usa
c:\windows, afectando sólo a las instalaciones por defecto de XP y
2003). Está escrito en VisualBasic y su vida útil es muy corta. De
hecho, a las pocas horas de analizarlo, la web fraudulenta a la que
redirigía al usuario era desactivada, con lo que el troyano queda ya
inutilizado (esa dirección se encontraba incrustada en su código).

Sin embargo este malware pasaba desapercibido para la totalidad de los
motores en VirusTotal.com. 24 horas después de nuestro estudio ya lo
detectan 3 motores, pero en el momento de ser lanzada la "campaña",
pasaba inmaculado cualquier análisis. Precisamente comienzan a
detectarlo cuando ya no sirve para nada, pero eso es otro problema.
En cualquier caso, no todo es simple en este tipo de ejemplares: este
tipo de troyano en concreto ofrece ciertas ventajas que permiten
“saltarse” el sistema de OTP (one time password) específico de la
entidad a la que ataca.

En estos días, esta simpleza de código, esta "cuasi-chapuza" con
inminente fecha de caducidad resulta todavía efectiva. Una especie de
involución que pilla desprevenidas a las tecnologías antivirus. En
este caso, lo único sofisticado es la ingeniería social usada para
intentar que el troyano sea ejecutado. El resto, un cambio en el
sistema que no muchos notarán pues serán redirigidos de forma casi
transparente (el certificado SSL no será válido, pero no es algo a lo
que muchos usuarios presten atención, se fijan más en una URL
correcta) a una web con idéntico aspecto que la original.

Si siempre hemos hablado de que los atacantes utilizan todas las
técnicas en su mano para inundar los buzones y buscar la máxima
infección, los métodos simples también tienen su espacio, por qué no.
Quizás no consigan un número de infecciones espectacular, pero son sin
duda un añadido más en una carrera de fondo contra las técnicas que
pretenden solucionarlos. Como las modas, lo "retro", lo "minimalista"
también tiene su hueco... "keep it simple, stupid!"


Sergio de los Santos
ssantos@hispasec.com


Más información:

20 días después
http://blog.hispasec.com/laboratorio/232

Cuando 30 antivirus no son suficientes
http://blog.hispasec.com/laboratorio/228

martes, 28 de agosto de 2007

Vulnerabilidad en función webcam de Microsoft Messenger 7.x

Se han publicado los detalles de una vulnerabilidad en MSN Messenger
que puede ser aprovechada por atacantes para ejecutar código
arbitrario en el sistema víctima. El programa, sin duda el más popular
utilizado para la mensajería instantánea, sufre de un fallo muy
parecido al que hace unas semanas se anunció en Yahoo! Messenger, otro
popular cliente de mensajería.

Microsoft MSN Messenger, llamado Live Messenger desde su versión 8.x,
apenas necesita presentación. Es el cliente de mensajería instantánea
más usado desde que Windows XP lo incorporara por defecto en su
instalación y desbancara al no menos popular ICQ, rey de la mensajería
en los primeros años de Internet. El programa no ha sufrido demasiados
problemas de seguridad en su versión 7.x, tampoco su versión 6.x
resultó especialmente problemática.

Sí que ha servido para la propagación de troyanos a través de
ingeniería social (enlaces en la conversación creados automáticamente
y aparentemente originados por algún contacto), también para lo que se
dio en llamar SPIM (SPAM over Instant Messenger) e incluso para el
intento de propagación de adware (winfixer) a través de las pancartas
de publicidad asociada que ofrece el programa.

El fallo publicado se debe a un error en el manejo de conversaciones
de vídeo. Si se envían datos especialmente manipulados, un atacante
podrá provocar un desbordamiento de heap y ejecutar código arbitrario
si la víctima acepta una invitación de cámara web. Este fallo es muy
similar al que se detectó a mediados de agosto en Yahoo! Messenger,
competencia directa de Microsoft en mensajería instantánea.

El fallo se ha encontrado en versiones 7.x y anteriores. La versión
8.1 parece que no se ve afectada por este problema, lo que mitiga en
parte el potencial impacto de la vulnerabilidad al ser la versión
mayoritariamente usada. No existe parche oficial. Se recomienda no
aceptar sesiones de cámara web no solicitadas y actualizar a la última
versión 8.1 desde http://get.live.com/messenger/.

Los usuarios de Windows 2000 lo tienen más complicado. Messenger 8.x
no se instalará en esta versión del sistema operativo, por lo que no
podrán actualizar hasta que aparezca el parche correspondiente. El
descubridor ha hecho público además un exploit para aprovechar el
fallo que dice funcionar para la versión China de Windows 2000, pero
que con algunas modificaciones, conseguiría ejecutar código en otros
idiomas. Microsoft no ha realizado aún comunicado alguno al respecto.


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

Microsoft MSN Messenger Video Conversation Handling Code Execution Issue
http://www.team509.com/modules.php?name=News&file=article&sid=50

lunes, 27 de agosto de 2007

Múltiples vulnerabilidades en Bugzilla 2.x y 3.x

Se han encontrado múltiples vulnerabilidades en Bugzilla que pueden ser aprovechadas por atacantes para inyectar código scripting arbitrario, comandos de consola u obtener información sensible.

Bugzilla es un sistema de base de datos para comunicar bugs y asignarlos a desarrolladores, lo que permite obtener una gran simplificación administrativa respecto a la gestión manual de bugs. Bugzilla se utiliza en numerosos proyectos, sobre todo del tipo "Open Source".

El primer fallo se debe a un error a la hora de validar datos del usuario que se le pasan al campo buildid. Esto puede ser aprovechado por un atacante para ejecutar código script arbitrario en el navegador de la víctima bajo el contexto de seguridad de la página afectada.

El segundo fallo se debe a un error de validación de entrada en la función Email::Send::Sendmail a la hora de procesar argumentos proporcionados por el usuario. Esto puede ser usado por un atacante para inyectar y ejecutar comandos de consola arbitrarios a través del script email_in.pl

El tercer fallo se debe a un error en la interfaz WebService (XML-RPC), que no restringe el acceso a ciertos campos. Esto puede ser aprovechado por atacantes para obtener información sensible.

Se recomienda actualizar a las versiones 2.20.5, 2.22.3 o 3.0.1 desde http://www.bugzilla.org/download/ o las herramientas automáticas propias de cada distribución.


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

Security Advisories
https://bugzilla.mozilla.org/show_bug.cgi?id=386942
https://bugzilla.mozilla.org/show_bug.cgi?id=386860
https://bugzilla.mozilla.org/show_bug.cgi?id=382056

domingo, 26 de agosto de 2007

Fin de ciclo de vida para BIND 8.x

La rama 8.x de BIND, uno de los servidores de nombres más populares,
deja de ser mantenida por el ISC (Internet Systems Consortium), de
forma que no se publicarán más parches de seguridad para esta versión.
Sus esfuerzos de desarrollo, a partir de ahora, se centrarán en la
rama 9.x.

BIND (también conocido como 'named') es el software servidor de
nombres de dominio (DNS) más popular en las diferentes versiones y
distribuciones de Unix. Se trata de un software desarrollado por el
ISC (Internet Software Consortium), un consorcio donde se encuentran
representadas algunas de las empresas más importantes del sector
informático y que tiene como objetivo el desarrollo de las
implementaciones de referencia de los principales protocolos básicos
de Internet. Esto hace que muchos sistemas operativos incluyan, de
forma nativa, BIND.

El 27 de agosto el ISC ha anunciado el fin de ciclo de vida para BIND
8.x, después de más de diez años desde su aparición estable en mayo de
1997. Desde entonces, la rama 8.x ha sido castigada por una gran
cantidad de fallos y vulnerabilidades que han hecho que BIND se haya
convertido históricamente en la puerta de entrada para muchos
servidores en Internet y una forma remota de engañar y redirigir la
navegación de los usuarios. A mediados de 2000 apareció la rama 9.x de
BIND, con un número de vulnerabilidades menor hasta el momento y capaz
de aprovechar nuevas tecnologías de los sistemas.

Muchos fallos en BIND han sido considerados siempre como de los más
peligrosos, manteniéndose en algunas listas especializadas de
vulnerabilidades siempre entre los 20 más críticos. Hay que tener en
cuenta que BIND es 'omnipresente': ha sido utilizado por innumerables
servidores en Internet, con acceso abierto a todo el que desease
resolver direcciones y dominios, además de estar presente por defecto
en muchas distribuciones. Las posibilidades de aprovechar fallos se
multiplican, y un error grave en este software abre muchas puertas a
potenciales atacantes.

La propia ISC reconoce que la rama 8.x fue escrita en otros tiempos,
cuando la seguridad no era una prioridad en Internet. Esto ha
provocado que, a marchas forzadas, el producto haya tenido que ser
parcheado hasta la saciedad para poder 'sobrevivir' en la Internet de
hoy día, con miles de ataques automátizados, sistemáticos y
sofisticados a todo puerto abierto y accesible en la Red.

La rama 8.x se despide con la versión BIND 8.4.7 P1, que además
soluciona un problema de seguridad que puede permitir a atacantes
perpetrar ataques de envenenamiento de caché.

El fallo se debe a una debilidad del algoritmo del sistema a la hora
de calcular identificadores para las transacciones. Un atacante remoto
podría envenenar la caché de un servidor BIND 8 si estudia el tráfico
de las transacciones y predecir así el siguiente valor. El método de
ataque es distinto al reportado hace algunas semanas y que afectaba a
BIND 9.x

Se recomienda actualizar con el parche P1 disponible desde:
ftp://ftp.isc.org/isc/bind8/src/8.4.7-P1/

Ya no hay excusa para no saltar a la rama 9.x que además de una mejor
seguridad y proporcionar un rendimiento mayor, queda como única
alternativa segura para los administradores que confíen en BIND.


Sergio de los Santos
ssantos@hispasec.com


Más información:

BIND 8 End Of Life Announcement
http://www.isc.org/index.pl?/sw/bind/

sábado, 25 de agosto de 2007

Escritura de ficheros arbitrarios en X-Diesel Unreal Commander

Descubiertas vulnerabilidades en X-Diesel Unreal Commander v.092
(build 574) que podrían ser aprovechadas por un atacante para
comprometer un sistema vulnerable sobreescribiendo archivos.

Unreal Commander es una premiada utilidad freeware para sistemas
Windows 98/ME/2000/XP/2003/Vista. La aplicación soporta múltiples
formatos de archivos, incluye un cliente de FTP y otras
funcionalidades.

Las vulnerabilidades tienen su origen al procesar archivos ZIP y RAR
malformados que provoquen una escalada de directorios, pudiendo
aprovechar el atacante para escribir ficheros en el sistema en
cualquier localización y no en la carpeta elegida por el usuario
legítimo. Es posible el compromiso total del sistema, especialmente
si el usuario ejecuta Unreal Commander con privilegios de
administrador.

Aunque el desarrollador ha sido avisado sobre el problema, aun no
ha publicado una actualización para corregir la vulnerabilidad. A
falta del parche, se recomienda a los usuarios de Unreal Commander
extremen la precaución al procesar ficheros ZIP o RAR de terceros
no confiables.

Toda la información y pruebas de concepto se pueden encontrar en
el aviso original: http://blog.hispasec.com/lab/231


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

X-Diesel Unreal Commander v0.92 (build 573) multiple vulnerabilities
http://blog.hispasec.com/lab/advisories/adv_UnrealCommander_0_92_build_573_Multiple_Vulnerabilities.txt

viernes, 24 de agosto de 2007

Escritura de ficheros arbitrarios en GNU tar 1.x

Se ha descubierto una vulnerabilidad en GNU tar que podría ser
aprovechada por un atacante para comprometer un sistema vulnerable
sobreescribiendo archivos.

Tar es una utilidad para manipular archivos usada principalmente para
reunir en un mismo fichero un conjunto de archivos, recuperarlos,
enviarlos a otros dispositivos... su nombre viene de “Tape ARchiver”,
porque originalmente fue concebido principalmente con la función de
envío a cintas.

La vulnerabilidad se debe a un fallo de rutas transversales en la
manera en que tar extrae archivos. Un atacante podría aprovechar esto
para escribir ficheros arbitrarios (fuera del directorio donde se
ejecuta el comando, usando “..”) con los privilegios del usuario que
ejecutase tar a través de un fichero especialmente manipulado. La
vulnerabilidad en concreto se encuentra en la función
contains_dot_dot.

GNU Tar está presente en la mayoría de distribuciones GNU/Linux
disponibles. Ha sido descubierta por el equipo de seguridad de
Red Hat.

Se recomienda actualizar el programa desde las herramientas
automáticas de cada distribución o el CVS y evitar el tratamiento con
tar de archivos no confiables.


Laboratorio Hispasec
laboratorio@hispasec.com



jueves, 23 de agosto de 2007

¿Spam, estafa, phishing, o marketing agresivo?

Aunque ya llevan un tiempo en buzones de todo el mundo, una nueva
estafa ha llegado al correo de dueños de dominios en España. Se trata
de un email personalizado que intenta que el propietario del dominio
en cuestión contrate unos servicios de renovación cuando menos dudosos
y a unos precios abusivos.

Marc Rabell, lector de una-al-día, nos remitía un correo no solicitado
que había recibido de la empresa Domain Renewal. Le indicaba que era
hora de renovar la contratación de un dominio que efectivamente le
pertenecía. Escrito en perfecto español, le hablaba de un servicio que
gestiona la renovación de su dominio y le indicaba un enlace en el que
aparece su dominio real como parámetro:

http://www.domainrenewal-online.com/for.php?d=cualquierdominio.com

Esta web, de apariencia profesional y traducida correctamente a varios
idiomas, se describe como “gestionadora” de dominios, de forma que a
través de acuerdos con ISPs previene su caducidad. Para dar sensación
de confianza, incluye logos de varias compañías de renombre como
Cisco, IBM, Oracle... Aparte de cobrar un precio abusivo por un dudoso
servicio, resulta curioso que pretenda ofrecerlo (cobrarlo) a toda
costa: independientemente del dominio que se le indique, sin comprobar
si realmente existe, intentará que se realice el pago.

Aunque pida los datos de la tarjeta de crédito esto no puede
considerarse un “phishing” como tal, pues no simula ni pretende
aparentar ser una entidad legítima reconocida. Además, la introducción
de los datos de la tarjeta se realiza a través de un tercero confiable
dedicado a pago seguro (multicards.com). Al menos desde hace algunas
semanas, porque según algunos afectados, hubo un tiempo en que
recolectaban los datos de la tarjeta desde la propia página de Domain
Renewal, procedimiento mucho más “delicado” y que podría conllevar al
robo no solo del dinero pagado sino de los datos para futuras estafas.

Lo interesante de este tipo de correo basura, una vez más, es lo
preciso y segmentado en su búsqueda de objetivos. A través de la
recolección de datos públicos como los que figuran en las bases de
datos “whois”, consiguen las direcciones de los legítimos dueños de
dominios para enviarles el correo basura e hilar así mucho más fino en
el ataque.

No es la primera vez que se observan este tipo de estafas
relacionadas con los dominios, ya en 2004 y 2006 se notificaron casos
similares, pero parece ser que a menor escala y pocas veces en España.
En cualquier caso, cada vez con mayor frecuencia, observamos este tipo
de estafas elaboradas, que requieren de un trabajo de campo previo y
huyen de las reglas habituales del spam masivo, impersonal y poco
sofisticado. A principios de junio, ya hicimos referencia en un
boletín a un elaborado intento de infección por email que engañó a
1.400 directivos de importantes empresas. Una supuesta carta de la
BBB (Better Business Bureau), perfectamente personalizada y redactada,
instaba a la ejecución de un programa que no era más que un troyano
bancario.

¿Les compensa ese trabajo previo? ¿Resulta el “éxito” mayor que el
que se pudiera obtener a través de una campaña de spam “habitual”? Los
spammers y estafadores deben realizar cálculos y balancear costes y
beneficios (envío masivo frente al personalizado, traducción
automática frente a textos cuidados...) en toda campaña tal y como lo
haría cualquier empresa que pretenda promocionar sus productos. La
industria así lo requiere.



Sergio de los Santos
ssantos@hispasec.com


Más información:

New Domain Name Renewal Scam Hits Inboxes
http://domainnamewire.com/2007/07/16/new-domain-name-renewal-scam-hits-inoxes/

Scam targets domain name holders
http://www.techworld.com/security/news/index.cfm?newsid=9518

(04/06/2007) Un elaborado intento de infección por email engaña a 1.400
directivos
http://www.hispasec.com/unaaldia/3145

miércoles, 22 de agosto de 2007

El resurgir del virus Storm : Exprimiendo el correo basura (III)

Una vez más, merece la pena detenerse ante un correo basura que está
inundando nuestros buzones (y por extensión, el de algunos millones
más de usuarios) durante estos días. Se trata de un spam que intenta
hacer que la víctima visite una página. Con cierta audacia, pretende
que se descargue un ejecutable y si no, aprovechar fallos para
infectar. Lo destacable en este caso, es la cantidad de variantes que
se están creando y su capacidad para pasar a través de los filtros
antispam.

Desde hace unos días estamos recibiendo decenas de correos con esta
estructura:

Dear Member, Welcome To XXXXXX

Membership Number: 43287941
Login ID: user4579
Temp Password ID: cy209

For security purposes please login and change the temporary Login ID
and Password. Follow this link, or paste it in your browser:
http://XX.XX.XX.XX/

Thank You, Support Department, XXXXXX

Donde XXXXX suele hablar de citas, MP3 o incluso cuidado de perros.
Las contraseñas son también aleatorias. Cuando se visita el enlace a
la dirección IP (situada en EEUU o Corea del Sur, entre otros) aparece
en el navegador una escueta frase:

“If you do not see the Secure Login Window please install our Secure
Login Applet”

Esto apunta a la descarga de applet.exe. Esta misma página, aunque no
se descargue el ejecutable, contiene un script oculto, codificado con
XOR que de forma automática intenta aprovechar vulnerabilidades del
navegador o plugins asociados con exploits conocidos. La potencial
víctima formará parte de las estadísticas de un servidor Mpack.

Una de las curiosidades de este ataque es la variedad de “applet.exe”
que están creando. Con tamaños parecidos, no parecen existir dos
iguales, variando siempre en un intento de pasar desapercibido ante
los antivirus. Sin embargo no lo consigue. Casi el 60% de los
antivirus en VirusTotal.com detectan las variantes como sospechosas o
como malware identificado. Resulta curioso (aunque ya habitual) como
prácticamente ningún motor se pone de acuerdo en su nomenclatura,
llamándolas casi de tantas formas distintas como motores y
detecciones. Parecen resultar ser variantes del storm worm, un virus
mediático del que se habló bastante a comienzos de 2007.

Otro interesante análisis es la capacidad de “no parecer spam” de este
correo sencillo en texto plano. Es puntuado muy bajo en el ratio de
"posibilidades de ser basura" que otorgan los programas antispam, y
se cuela fácilmente en filtros incluso sofisticados. Coexisten en esta
basura dos técnicas contrapuestas. Los spammers están tendiendo a
técnicas efectivas y sofisticadas ayudándose de archivos adjuntos en
PDF e incluso FDF para eludir filtros. Por otro lado, los que intentan
infectar con troyanos han encontrado en la “sencillez” del mensaje y
en el apoyo en servidores web para alojar el malware (eliminando así
el adjunto y el potencial bloqueo de los antivirus), las
características para llegar a sus víctimas.


Sergio de los Santos
ssantos@hispasec.com


Más información:

18/06/2007 Malware alojado en dominios .hk: Exprimiendo el correo basura (II)
http://www.hispasec.com/unaaldia/3159

07/06/2007 Nuevas técnicas de spam: Exprimiendo el correo basura
http://www.hispasec.com/unaaldia/3148

22/01/2007 El mediático troyano de la tormenta y las lecciones no aprendidas
http://www.hispasec.com/unaaldia/3012


martes, 21 de agosto de 2007

Denegación de servicio en ClamAV 0.x

Se ha anunciado la aparición de una nueva versión de ClamAV que
soluciona varias vulnerabilidades que podrían llegar a ser
aprovechadas por atacantes para provocar una denegación de servicio en
el sistema víctima. Por ejemplo, a través de un correo adjunto que sea
procesado por el motor antivirus.

ClamAV es un motor antivirus de código abierto muy popular en el mundo
del software libre, empleado con frecuencia en servidores de correo
derivados de UNIX a modo de defensa perimetral primaria. Hace apenas
unos días este proyecto ha sido adquirido por la compañía Sourcefire,
lo que sin duda supondrá un cambio importante (todavía desconocido) en
su evolución.

En este caso, los fallos corregidos son:

* Una referencia a puntero nulo en la función cli_scanrtf de
libclamav/rtf.c. Si se envía un fichero RTF especialmente manipulado,
podría hacer que el programa dejase de responder.

* Una referencia a puntero nulo en la función cli_html_normalise de
libclamav/htmlnorm.c. Si se envía un fichero HTML especialmente
manipulado, podría hacer que el sistema dejase de responder.

Las versiones afectadas son las anteriores a la 0.91.2. Se recomienda
actualizar a la última versión desde
http://sourceforge.net/project/showfiles.php?group_id=86638&package_id=90197&release_id=533658.

Los últimos problemas de seguridad de este antivirus han tenido lugar
en julio, con una denegación de servicio a través de archivos RAR y
una de las más graves, en agosto de 2006, con la posibilidad de
ejecución de código a través de archivos UPX.


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

Denegación de servicio a través de ficheros RAR en ClamAV
http://www.hispasec.com/unaaldia/3187

10/08/2006 Desbordamiento de búffer en ClamAV por error en tratamiento
de archivos UPX
http://www.hispasec.com/unaaldia/2847

Clam AntiVirus new relsease
http://sourceforge.net/project/shownotes.php?release_id=533658&group_id=86638

lunes, 20 de agosto de 2007

Múltiples vulnerabilidades en Fileinfo 2.0.9

Detectadas vulnerabilidades en Fileinfo al procesar ejecutables
especialmente diseñados para la ocasión. Los efectos de la explotación
pueden ir desde un ataque DoS hasta forzar que la utilidad muestre
datos falsos sobre el propio ejecutable.

Fileinfo es un plugin para Total Commander, desarrollado por Francois
Gannier, que permite a los usuarios ver la estructura de archivos
con formatos MZ, PE y COFF.

Se ha descubierto que es posible causar una denegación de servicio o
que la utilidad muestre datos falsos sobre diversos parámetros y la
propia estructura de un archivo con formato Portable Executable
(PE).

Todos los detalles, incluyendo pruebas de concepto, se pueden
encontrar en el aviso original:
http://blog.hispasec.com/lab/advisories/adv_Fileinfo-2_09_multiple_vulnerabilities.txt

Aunque el desarrollador de la utilidad ha sido informado, aun no se
ha publicado una actualización que corrija el problema. Hasta
entonces, se recomienda a los usuarios de Fileinfo que aumenten las
precauciones al visualizar información de ejecutables PE de fuentes
no confiables.


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

Fileinfo 2.0.9 multiple vulnerabilities
http://blog.hispasec.com/lab/230

Fileinfo
http://www.totalcmd.net/plugring/fileinfo.html

domingo, 19 de agosto de 2007

Vulnerabilidad en Lhaz 1.33

La utilidad de compresión Lhaz, en su versión 1.33, posee una
vulnerabilidad que permite ejecutar código arbitrario de forma
remota. Se recomienda su actualización a la reciente versión
1.34b2, que corrige el problema, o prevenir el uso de la
herramienta para tratar archivos no confiables.

La vulnerabilidad puede ser aprovechada a través de un archivo
gzip especialmente construido que provoca la ejecución arbitraria
de código al intentar ser descomprimido con Lhaz 1.33.

El exploit ha sido detectado in-the-wild (utilizándose de forma
activa) en sitios japoneses con el fin de instalar un backdoor
entre los usuarios de Windows con una versión de Lhaz vulnerable.
De momento se estima que el ataque haya tenido apenas incidencia
entre usuarios europeos o de habla española.

En las últimas horas se ha publicado dos betas de la nueva
versión 1.34. Si algún usuario utiliza Lhaz tiene dos opciones
para prevenir el ataque:

* No manejar con Lhaz archivos ZIP no confiables a la espera de
instalar la versión 1.34 definitiva

* Instalar la versión 1.34b2

La última versión de Lhaz puede ser descargada desde su página
web: http://www.chitora.jp/lhaz.html


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

Targeted Zero-day Attack Against Free Tools - LHAZ
http://www.avertlabs.com/research/blog/index.php/2007/08/17/targeted-zero-day-attack-against-free-tools-lhaz/

Exploit-LHAZ.a
http://vil.nai.com/vil/content/v_142976.htm

Lhaz
http://www.chitora.jp/lhaz.html

sábado, 18 de agosto de 2007

El escarabajo de oro

La lectura de "El escarabajo de oro", relato de Edgar Allan Poe, ha
supuesto para muchos el bautismo con el criptoanálisis, descubriendo
uno de los métodos básicos para romper un mensaje cifrado y recuperar
la información original.

Edgar Allan Poe es tal vez más conocido por sus obras de misterio e
historias macabras, si bien también fue un apasionado de la
criptografía. Esa afición ha quedado reflejada para la posteridad
con mensajes ocultos en varios de sus poemas y de forma más explícita
en "El escarabajo de oro".

Esa faceta se hizo aun más patente cuando en 1839 comenzó a escribir
en la publicación Alexander's Weekly Messenger una serie de artículos
sobre criptografía, llegando a retar a sus lectores a que le enviaran
mensajes cifrados que él intentaría resolver.

Su colaboración con la publicación apenas duró 5 meses. Un año más
tarde comenzó de nuevo a escribir sobre criptografía en la publicación
Graham's Magazine, bajo el título "A Few Words on Secret Writing"
y una serie de tres artículos. En esta publicación afirmó que durante
el transcurso del anterior reto logró resolver todos los mensajes
cifrados enviados por los lectores de Messenger, aproximadamente unos
cien.

Según Poe, recibió dos nuevos mensajes cifrados de un lector,
Mr. W.B. Tyler, que reprodujo en Graham's Magazine para animar a sus
lectores a que intentaran descifrarlos. Poe afirmó que no había
podido resolverlos por falta de tiempo. Siempre se tuvo la sospecha
de que la historia era una excusa, y que Tyler era en realidad Poe,
que habría dejado de esta forma algún mensaje oculto para la
posteridad.

El primero de los mensaje cifrados de Tyler no fue resuelto hasta
pasados más de 150 años, en 1992, por Terence Whalen, un estudioso de
la obra de Poe, que a día de hoy ejerce en la universidad de Illinois

Este primer mensaje resultó ser un fragmento de "Cato", obra de
Joseph Addison que data de 1713, y que a priori no establece relación
alguna con Poe. En cuanto al sistema de cifrado utilizado, tampoco
resultó ser nada sofisticado, se trataba de una simple sustitución
monoalfabética, que podía ser resuelta de forma similar a como se
describe en "El escarabajo de oro".

El segundo mensaje cifrado de Tyler seguía resistiendose. En 1996,
Shawn J Rosenheim, profesor del Williams College y estudioso de Poe,
anunció un concurso por el que premiaría con 2.500 dólares a la
persona que descifrara el segundo mensaje de Tyler.

En el año 2000 Gil Broza, actualmente consultor IT, se alzaría con
el premio al resolver el segundo mensaje de Tyler con la ayuda de
un ordenador, varios programas que diseñó para la ocasión, y dos
meses de quebraderos de cabeza. El texto descifrado resultó ser de
lo más decepcionante, ya que no se ha establecido su autoría y a
priori no guarda relación alguna con Poe. Aun así, continúan las
teorías sobre que Poe pudiera ser el autor de estos mensajes
cifrados y que, una vez descifrados, aun pudiera contener algún
mensaje oculto que aun no habría sido interpretado.

Si has llegado hasta aquí y no conocías la obra de Poe o te has
interesado por el criptoanálisis, tal vez te apetezca leer "El
escarabajo de oro":

(PDF) http://www.librosgratisweb.com/pdf/poe-edgar-alan/el-escarabajo-de-oro.pdf
(PDF) http://www.estadisticaparatodos.es/taller/criptografia/Edgar_Allan_Poe-El_Escarabajo_de_oro.pdf
(HTML) http://es.wikisource.org/wiki/El_escarabajo_de_oro


Bernardo Quintero
bernardo@hispasec.com


Más información:

Edgar Allan Poe
http://en.wikipedia.org/wiki/Edgar_Allan_Poe

The Edgar Allan Poe Cryptographic Challenge
http://www.bokler.com/eapoe.html

Terence Whalen
http://www.uic.edu/depts/engl/faculty/prof/twhalen/bio.htm

Shawn J Rosenheim
http://www.williams.edu/English/people/faculty/SRosenheim.htm

Gil Broza
http://www.cutter.com/meet-our-experts/brozag.html

El escarabajo de oro
http://es.wikisource.org/wiki/El_escarabajo_de_oro
http://www.librosgratisweb.com/pdf/poe-edgar-alan/el-escarabajo-de-oro.pdf
http://www.estadisticaparatodos.es/taller/criptografia/Edgar_Allan_Poe-El_Escarabajo_de_oro.pdf

viernes, 17 de agosto de 2007

Vulnerabilidad crítica en Yahoo! Messenger

Una vulnerabilidad en el popular cliente Yahoo! Messenger podría
comprometer los sistemas de forma remota al aceptar una invitación de
conexión por webcam. A falta de la publicación de un parche por parte
de Yahoo!, se recomienda a los usuarios tomen algunas medidas de
prevención.

Según se ha publicado en el blog de McAfee Avert Labs, los detalles
del exploit para aprovechar la vulnerabilidad se publicaron en algunos
foros de seguridad en China, y ha podido ser reproducido con éxito
en Yahoo! Messenger versión 8.1.0.413.

A falta del parche, las recomendaciones para prevenir incidentes son:

* No aceptar invitaciones por webcam de terceras partes no confiables

* Bloquear el tráfico de salida en el puerto TCP/5100

Esperamos que, hasta la publicación de una actualización, los usuarios
de Yahoo! Messenger puedan resistirse a las invitaciones por webcam,
por muy sugerentes que éstas puedan ser.


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

More on the Yahoo Messenger Webcam Zero-Day
http://www.avertlabs.com/research/blog/index.php/2007/08/15/more-on-the-yahoo-messenger-webcam-0day/


jueves, 16 de agosto de 2007

Compran al antivirus ClamAV

Sourcefire ha anunciado la compra de ClamAV a los cinco líderes del
popular proyecto open source. Como era de esperar, el anuncio ha
suscitado todo tipo de reacciones en la comunidad ClamAV.

Tomasz Kojm, uno de los miembros del núcleo de ClamAV, daba a conocer
la noticia en las listas públicas agreciendo a la comunidad el duro
trabajo y dedicación al proyecto. Además presentaba la adquisición
por parte de Sourcefire como una fuente de nuevos recursos para
seguir trabajando con la comunidad en el avance de ClamAV.

A continuación detallaba que, aunque ellos seguirán en el equipo
desarrollador, a partir de ahora Sourcefire asume todo el control y
es dueño del proyecto ClamAV, incluyendo desde el dominio y todo el
contenido de clamav.org, hasta el código fuente desarrollado por
los cinco miembros principales.

De cara a los usuarios finales, Tomasz asegura que notarán pocos
cambios y, la parte más importante a priori, que el motor de ClamAV
y su base de datos de firmas seguirán bajo licencia GPL.

Pese a lo cuidado del anuncio, a nadie escapa que habrá un antes y
un después. La adquisición de proyectos de seguridad open source
suele acabar dando lugar a versiones comerciales "mejoradas" en
detrimento de la gratuita. Ya no sólo se trata del soporte
profesional, sino que la versión comercial suele tener ventajas
en forma de funcionalidades, rendimiento y/o periodicidad de las
actualizaciones.

Desde el punto de vista empresarial es lógico, ya que este tipo de
herramientas no suelen requerir mucho soporte y de algún modo deben
marcar las ventajas para fomentar la venta de la versión comercial.

Sin ir más lejos, ha ocurrido con los proyectos open source de
seguridad más conocidos, como el escaner de vulnerabilidades Nessus
o el detector de intrusos Snort, éste último precisamente de
Sourcefire. En ambos casos, además de las mejoras en los motores y
funcionalidades añadidas, las versiones comerciales tienen mayor
periodicidad en las actualizaciones de firmas. Este esquema sería
desastroso en el caso de ClamAV, que como todo motor antivirus
tiene una gran dependencia de las firmas, pero especialmente
ClamAV por la ausencia de otro tipo de tecnologías de detección más
genéricas, por lo que desde Hispasec creemos y esperamos que no se
lleve a cabo esta política.

Respecto al nuevo enfoque comercial, el CEO de Sourcefire, Wayne
Jackson, ha declarado que además de dar soporte y formación,
crearán una nueva licencia para los proveedores que utilicen el
motor en terceros productos, y que no necesariamente se acogerá a
la GPL.

Teóricamente, ahora debe iniciarse una "limpieza" del código fuente
para identificar las partes que ha aportado la comunidad y
determinar exáctamente cual es el código que pasa a ser propiedad
de Sourcefire. También queda por comprobar cual es la reacción de
la comunidad a la hora de seguir apoyando el desarrollo y la
inclusión de nuevas firmas de detección.

Es de preveer que a corto plazo no habrá cambios importantes, será
con el paso del tiempo cuando se pueda hacer una lectura de esta
adquisición y ver finalmente si ha sido beneficiosa o perjudicial
para la comunidad de usuarios de ClamAV.


Bernardo Quintero
bernardo@hispasec.com


Más información:

Sourcefire Acquires ClamAV Open Source Network Anti-Virus Project
http://investor.sourcefire.com/phoenix.zhtml?c=204582&p=irol-newsArticle&ID=1041607&highlight=

Sourcefire acquires ClamAV open-source anti-malware project
http://www.infoworld.com/article/07/08/17/Sourcefire-acquires-open-source-AV-project_1.html

FAQ Sourcefire-ClamAV
http://www.clamav.org/support/sf-faq

miércoles, 15 de agosto de 2007

Fraude a la banca electrónica con OTP

No es nada nuevo y además era previsible. Los usuarios de entidades
que han implantado sistemas basados en OTP comienzan a sufrir con
regularidad ataques de phishing y troyanos.

Los sistemas de autenticación OTP (One Time Password), que al español
se traduciría como "contraseña de un solo uso", son aquellos que
requieren una contraseña nueva cada vez que se utiliza. Una especie de
contraseña de usar y tirar, que minimiza el impacto de que un tercero
pueda capturarla.

La idea es que si alguien o algo espía y averigua que introduzco la
clave "390827" para entrar o firmar una operación en mi banca
electrónica, ese dato no le servirá para suplantarme. Ya que la
próxima vez que entre en mi banca electrónica la clave será
otra diferente: "220948".

Por norma general los sistemas OTP están asociados a unos tokens
hardware que son los que generan la clave correcta en función de
determinados parámetros (clave anterior, sincronización por tiempo con
el servidor de autenticación, etc). A efectos prácticos, el caso más
común es que el usuario cuente con un dispositivo, similar a un
llavero o una tarjeta, que al pulsar un botón devuelve en su pantalla
la nueva clave. Algunos ejemplos gráficos cortesía de Google:
http://images.google.com/images?svnum=10&q=one+time+password

Este sistema de autenticación se empieza a prodigar cada vez más entre
entidades bancarias como clave de firma u operaciones, en combinación
con el usuario y contraseña estática de toda la vida. Es decir, para
entrar a nuestra cuenta nos pediría usuario y contraseña normales, y
para realizar algunas operaciones sensibles, como por ejemplo una
transferencia, nos solicitaría la contraseña dinámica OTP.

Con la combinación de ambos sistemas tenemos la tan traida y llevada
autenticación por doble factor: algo que el usuario sabe (el usuario y
contraseña estática), y algo que el usuario tiene (el hardware OTP).
La idea es que si al usuario le sustraen el usuario y contraseña
estática el estafador no pueda realizar transacciones, y si el usuario
pierde el token OTP tampoco puedan aprovecharlo porque no conocen el
usuario y contraseña de acceso. En resumen, complican la vida al
hipotético atacante.

Un ejemplo de pseudo token OTP primitivo y económico, tal vez más
cotidiano entre usuarios españoles, es la tarjeta de coordenadas con
claves que algunas entidades utilizan como contraseña de operaciones.
Suele tratarse de una tarjeta de plástico, similar a una tarjeta de
crédito, con una matriz de casillas que contienen diferentes claves
impresas. Cada vez que realizamos una operación la entidad nos pedirá
una coordenada, por ejemplo la C4 (fila C, columna 4), y tendremos
que introducir la contraseña de esa casilla.

Aunque estos sistemas de autenticación de doble factor son siempre más
robustos que el tradicional usuario y contraseña estática, no son
infalibles. De hecho hasta la fecha se han dado contados ataques más o
menos sofisticados: páginas de phishing normales y corrientes
solicitando la próxima clave del token hardware (en caso de que el
algoritmo de generación esté basado en la anterior clave y no
sincronizado con el tiempo), páginas de phishing que realizan ataques
"hombre en medio" en tiempo real en caso de que el OTP si esté basado
en la sincronización del tiempo, pasando por algunos más rústicos pero
no menos efectivos como pedir al usuario que envíe una fotocopia por
fax de su tarjeta de coordenadas, hasta los troyanos más avanzados
que inclusive burlan esquemas basados en la firma digital.

Si bien las debilidades de estos sistemas suelen ser conocidas (aunque
de vez en cuando alguien se sorprende cuando hablamos de los posibles
vectores de ataque, sobre todo contra la firma digital), su
implantación supone un aumento real de la seguridad para el cliente y,
hasta la fecha, un descenso de las campañas de fraude contra la
entidad.

Es lógico pensar que dada dos entidades bancarias, una que utiliza
usuario y contraseña estática frente a otra que utiliza doble factor
de autenticación, el estafador fije su atención en la que tiene el
sistema de autenticación más débil. No en vano, el estafador siempre
busca la mayor rentabilidad, y ésta la encuentra en el sistema de
autenticación tradicional: menor esfuerzo en el ataque (diseñar una
página de phishing es muy simple) y mayor cantidad de posibles
víctimas (el usuario tan sólo tiene que introducir su usuario y
contraseña y le servirá para suplantarlo indefinidamente).

Así era, y sigue siendo, sin embargo se observa con preocupación el
aumento de ataques contra sistemas OTP. Lo que hasta la fecha se
venía observando como ataques aislados o pruebas de concepto,
comienza a repetirse con cierta regularidad.

Un ejemplo reciente contra sistemas OTP puede verse en:
http://blog.hispasec.com/laboratorio/233

Es natural que a medida que se popularicen estos sistemas de
autenticación también evolucionen las estafas y ataques. En algunos
casos ni siguiera es necesario un avance tecnológico, basta con
la picaresca para hacer caer el eslabón más débil del sistema.

Ésto no debe ser excusa para que las entidades que utilizan
exclusivamente contraseñas estáticas no evolucionen e implementen
nuevos sistemas de autenticación. Aunque no hay sistema infalible,
la contraseña estática es la más vulnerable a todos los ataques.

El OTP tradicional, aunque es mucho más robusto y recomendable que
la contraseña estática, empieza a ser un objetivo, hay que seguir
avanzando. Al fin y al cabo, no deja de ser una carrera de fondo
en la que de vez en cuando las entidades deben dar un tirón, para
distanciarse del pelotón, diferenciarse, y dejar de ser una
víctima rentable ante los ataques mayoritarios.


Bernardo Quintero
bernardo@hispasec.com


Más información:

Phishing al OTP de Banamex (NetKey)
http://blog.hispasec.com/laboratorio/233

martes, 14 de agosto de 2007

Boletines de seguridad de Microsoft en agosto

Tal y como adelantamos, este semana Microsoft ha publicado nueve
boletines de seguridad (MS07-042 al MS07-050) dentro de su ciclo
habitual de actualizaciones. Según la propia clasificación de
Microsoft seis de los boletines presentan un nivel de gravedad
"crítico", mientras que los tres restantes se catalogan como
"importantes".

Los catalogadas por Microsoft como críticos:

* MS07-042: Resuelve una vulnerabilidad en Microsoft XML Core Services
que puede permitir la ejecución remota de código si un usuario visita
con Internet Explorer una página web especialmente diseñada a tal
efecto.

* MS07-043: Similar a la anterior, la vulnerabilidad resuelta puede ser
explotada a través de la vinculación e incrustación de objetos (OLE),
y puede permitir la ejecución remota de código al visitar una página
web diseñada al efecto.

* MS07-044: Actualización que corrige una vulnerabilidad que permitía
la ejecución remota código al abrir un archivo de Excel especialmente
diseñado.

* MS07-045: Esta actualización resuelve tres vulnerabilidades en
Internet Explorer que permiten la ejecución remota de código al visitar
una página web diseñada al efecto.

* MS07-046: Resuelve vulnerabilidad en el motor de representación de
gráficos (GDI) al procesar determinadas imágenes, que podía ser
aprovechada por un atacante para ejecutar código de forma remota si
la víctima abre un archivo especialmente diseñado.

* MS07-050: Actualización de seguridad para vulnerabilidad en la
implementación del lenguaje de marcado vectorial (VML) en Windows.
Podría ser aprovechada para la ejecución de código remota si el
usuario visita con Internet Explorer una página web diseñada al
efecto.


Los catalogadas por Microsoft como importantes:

* MS07-047: Actualización que corrige dos vulnerabilidades en el
reproductor de Windows Media que podrían ser aprovechadas para la
ejecución remota de código.

* MS07-048: Actualización que corrige dos vulnerabilidades en gadgets
de Windows Vista que permitiría la ejecución de remota de código si el
usuario se suscribe a una fuente RSS maliciosa del gadget Encabezados
de la fuente, ha agregado un archivo de contactos malintencionado en
el gadget Contactos o ha hecho clic en un vínculo malicioso del gadget
El tiempo.

* MS07-049: Esta actualización corrige dos importantes
vulnerabilidades en Virtual PC y Virtual Server que podrían permitir
la elevación de privilegios. Un usuario del sistema operativo invitado
con permisos de administrador podría ejecutar código en el sistema
operativo host o en otros sistemas operativos invitados.

Las actualizaciones publicadas pueden descargarse a través de Windows
Update o consultando los boletines de Microsoft donde se incluyen las
direcciones de descarga directa de cada parche. Dada la gravedad de
las vulnerabilidades se recomienda la actualización de los sistemas
con la mayor brevedad posible.


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

Boletín de seguridad de Microsoft MS07-042 - Crítico
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-042.mspx

Boletín de seguridad de Microsoft MS07-043 - Crítico
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-043.mspx

Boletín de seguridad de Microsoft MS07-044 - Crítico
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-044.mspx

Boletín de seguridad de Microsoft MS07-045 - Crítico
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-045.mspx

Boletín de seguridad de Microsoft MS07-046 - Crítico
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-046.mspx

Boletín de seguridad de Microsoft MS07-050 - Crítico
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-050.mspx

Boletín de seguridad de Microsoft MS07-047 - Importante
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-047.mspx

Boletín de seguridad de Microsoft MS07-048 - Importante
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-048.mspx

Boletín de seguridad de Microsoft MS07-049 - Importante
http://www.microsoft.com/spain/technet/security/Bulletin/MS07-049.mspx


lunes, 13 de agosto de 2007

Microsoft publicará nueve boletines de seguridad mañana martes

En su ciclo habitual de actualizaciones los segundos martes de cada
mes, Microsoft ha anunciado que en esta ocasión se esperan nueve
boletines de seguridad, seis dedicados a su sistema operativo Windows,
uno a Office, otro compartido entre la suite y el sistema operativo y
por último uno relativo a Virtual PC.

Si en julio fueron seis boletines de seguridad que salieron a la luz,
este mes Microsoft prevé publicar nueve actualizaciones el día 14 de
agosto. Al menos uno para Windows alcanza la categoría de crítico.
Igual para Office, donde el fallo resulta crítico. El de Microsoft
Virtual PC tiene categoría de “importante”.

Adicionalmente, y como viene siendo habitual, Microsoft publicará una
actualización para Microsoft Windows Malicious Software Removal Tool.
Además, se publicarán cuatro actualizaciones de alta prioridad no
relacionadas con la seguridad.

El fallo en el ActiveX de Office descubierto a mediados de junio, del
que existe exploit público y no actualización oficial, no parece estar
siendo explotado de forma masiva. No se sabe si será corregido en esta
ocasión. También se conoce un fallo “compartido” que ha dado que
hablar en los últimos días, y que puede corresponder a uno de los
parches de este mes.

Este problema (descrito en boletines anteriores) se debe a un fallo de
validación de entrada en el manejo de URIs. Direcciones (URIs) de
protocolos como mailto:, nntp:, snews:, telnet:, news:... pueden ser
modificadas para lanzar cualquier programa del sistema en vez del
cliente de correo, por ejemplo. Esto puede ser aprovechado para
ejecutar código arbitrario en vez del programa que debería
gestionarlos si un usuario de Windows, a través de otro programa,
visita una web especialmente manipulada con una URI que contenga el
carácter "%" y termine con extensiones ejecutables como .bat y .cmd.

Para reproducir el problema, Internet Explorer 7 debe estar instalado
en el sistema y (se creía en un principio) era necesario visitar la
página con Firefox, Netscape o Mozilla. Sólo funciona sobre Windows XP
y 2003, no sobre Vista.

Firefox (aunque luego se comprobó que no era el único programa que
podía ser usado como trampolín de la vulnerabilidad) corrigió su parte
del problema en la reciente versión 2.0.0.6, aunque no del todo y de
forma provisional. Parece que es responsabilidad de Microsoft atajar
el fallo de raíz y quizás lo haga con uno de los parches de este
ciclo.

Hispasec Sistemas publicará puntualmente a través de este boletín
información detallada sobre los nuevos parches.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Microsoft Security Bulletin Advance Notification for August 2007
http://www.microsoft.com/technet/security/bulletin/ms07-aug.mspx

31/07/2007 Fallos "compartidos" y actualización de productos Mozilla
http://www.hispasec.com/unaaldia/3202

domingo, 12 de agosto de 2007

Malware caducado

En la época de los virus para DOS los especímenes se mantenían activos
durante años. Hoy día el malware no suele ser autosuficiente, sino que
depende de una infraestructura basada en servidores en Internet con
los que se comunica. Cuando esa infraestructura es desactivada, el
malware ya no es útil para sus propósitos.

Los que somos menos jóvenes (o más viejos) recordaremos a virus como
Viernes 13, Brain, Ping-Pong, Barrotes, etc. Además de por ser los
primeros con los que nos topamos, perduran en nuestra memoria porque
estuvieron con nosotros mucho tiempo.

Cuando los virus eran virus, es decir, cuando se autoreplicaban de
archivo en archivo o de disco en disco, las epidemias eran más
similares a la de los virus biológicos. Un virus aparecía en una zona
geográfica concreta, por ejemplo en una universidad, y su área de
influencia iba propagándose de forma lenta a través de los usuarios
que compartían disquetes y archivos infectados. Tenía que transcurrir
varios meses para llegar a ser una epidemia de ámbito internacional.

No había forma de erradicarlos completamente. El virus era
autosuficiente, así que en cualquier momento y lugar podía aparecer
un nuevo brote si los ordenadores que tenían contacto con el virus no
contaban con un antivirus actualizado.

Con la explosión de Internet aparecieron los gusanos de propagación
masiva por correo electrónico. La distribución de éstos era mucho más
explosiva, en apenas unas horas podían dar la vuelta al mundo y llegar
a cientos de miles de sistemas. También perduraban en el tiempo,
algunas variantes de Netsky han dado la lata durante muchos meses en
los Tops de clasificación de malware.

Ahora que vivimos la época de los troyanos con fines lucrativos, nos
topamos con un malware mucho menos perenne, de usar y tirar, que
necesita reciclarse constantemente con nuevas variantes, y que da
lugar a gran cantidad de especímenes caducados.

Por un lado tenemos que los troyanos no son autosuficientes en su
distribución/replicación, a diferencia de los virus y gusanos que ellos
mismos se encargan de llegar a otros PCs. Hoy día los troyanos se
distribuyen en alguna campaña puntual de spam, o a través de la web.
Pasado ese primer envío masivo y manual, o desactivada la web desde
la que se distribuye, esa variante del troyano es probable que nunca
más vuelva a distribuirse.

Además, los propios troyanos suelen tener una dependencia de
infraestructura externa. Imaginemos un troyano "downloader" que se
encarga de descargar otros componentes. En el momento que se desactiva
el servidor desde donde realiza las descargas, ya no podrá llevar a
cabo su acción.

Pensemos ahora en el autor del troyano Gpcode. Lo distribuye a través
de spam. En las máquinas que se ejecuta, el troyano cifra los
archivos sensibles del ordenador (documentos, imágenes, y un largo
etcétera de extensiones), y pide un rescate al usuario para descifrar
y volver a recuperar esos archivos. La forma de contacto es una
dirección de e-mail en un servidor de correo público de Rusia. Cuando
las autoridades consiguen que el proveedor del servicio de correo
desactive esa dirección de e-mail, esa versión del troyano será
inútil para el autor ya que no puede ponerse en contacto con sus
víctimas para llevar a cabo el chantaje y, por tanto, no volverá a
utilizarla ni distribuirla. Deberá crear una nueva versión.

Situaciones similares se pueden dar con muchos otros tipos de
troyanos, por ejemplo, un malware dedicado a hacer pharming local para
redirigir a los usuarios infectados a páginas de phishing cuando
visiten determinados bancos. Lo que hace el troyano es modificar el
archivo hosts de Windows para redirigir los dominios de un determinado
banco a la IP del servidor web que hospeda las páginas falsas. Cuando
el banco tiene conocimiento de este tipo de fraude inicia una
actuación para desactivar las páginas de phishing. En el momento que
lo logra, que suele ser cuestión de horas, a lo sumo días, el troyano
será inútil, nunca más se distribuirá de nuevo. El autor se verá
obligado a crear nuevas versiones.

Un ejemplo de este último caso puede verse en:
http://blog.hispasec.com/laboratorio/232

La realidad es que un porcentaje del malware específico que detecta
un antivirus ya está "fuera de mercado", no nos afectará. Si los
antivirus deben detectar ese "malware caducado" es una cuestión que
no sólo depende de ellos, ya que las evaluaciones antivirus actuales
fomentan lo contrario: que se detecte de todo, incluso muestras que
no son dañinas. Si los antivirus tienen problemas para diferenciar
el malware, del grayware y el goodware, los evaluadores y
comparativas antivirus sencillamente no saben.

Al ritmo actual del crecimiento del número de variantes, el mantener
firmas de detección de todo el malware histórico podría dar lugar a
algunos problemas de tamaño/rendimiento. Hace ahora algo más de 4
años denominé el problema como "efecto ZOO", en la noticia
http://www.hispasec.com/unaaldia/1562

Entonces el problema del tamaño de firmas parecía no preocupar a los
desarrolladores antivirus, ya que el principal cuello de botella es
el acceso a los archivos a analizar.

Hoy día sigue siendo manejable, al menos en cuanto a volumen que no
a estrategia, pero la curva de crecimiento sigue imparable y amenaza
con pasar a medio plazo de la necesidad de reconocer 20.000 muestras
hace unos años a 2 millones. ¿Seguimos anclados como las comparativas
pidiendo que los antivirus detecten de todo aunque no nos afecte?
¿O pedimos antivirus modernos adaptados a una realidad diferente?


Bernardo Quintero
bernardo@hispasec.com



sábado, 11 de agosto de 2007

Donde más duele

Una publicación norteamericana afirma que las pérdidas por fraude
online en los últimos dos años alcanzan la cifra de 7.000 millones de
dólares.

El panorama del fraude online sigue demostrando ser altamente
rentable. La publicación norteamericana Consumer Reports ha realizado
recientemente una encuesta de la que se han sacado cifras por las que
los usuarios deberían - de una vez - empezar a tomarse muy en serio
este fenómeno: han estimado que la pérdida económica debida a malware
y phishing supera los 7.000 millones de dólares en el último par de
años, sólamente en territorio estadounidense y entre usuarios
particulares.

Este estudio, realizado sobre un grupo de 2.000 personas en total,
arroja otros datos que confirman el triste escenario sobre el que
campan los delincuentes de este tipo: el porcentaje de gente que
estaría respondiendo con información personal a ataques phishing es
del 8% (una cifra que creemos bastante exagerada), un tercio del total
no usaría software que les proteja contra spyware, el 17% no usaba
software antivirus y aproximadamente 3.7 millones de usuarios no
utilizarían firewalls para proteger su conexión vía banda ancha.

Es absolutamente imprescindible que el usuario medio entienda que
mantener la seguridad de su equipo no es sólo una cuestión de buenas
prácticas, sino que es algo que le puede afectar de forma muy
plausible y dolorosa. Para ponérselo fácil, hay que exponerlo dando
donde más duele: un sistema sin unos mínimos en seguridad es un
auténtico coladero por el que puede salir volando tu dinero.

La tendencia actual al uso de malware silencioso para realizar este
tipo de delitos mezcla perfectamente bien con la desidia general a la
hora de actualizar el sistema operativo o los programas que en él
residen. Esto resulta especialmente penoso dado que hoy día además es
fácil hacerse con un conjunto de herramientas gratuitas (o no) que
aumenten el nivel técnico de seguridad en nuestros sistemas, aunque al
final el factor decisivo será siempre el humano.

Desgraciadamente es extremadamente difícil luchar contra la candidez
de muchos usuarios que ya de primeras se acercan al ordenador como si
éste les fuera a morder, poniéndole las cosas fáciles a los criminales
online. El clásico ejemplo de persona que se infectó vía email o
programa de mensajería instantánea porque 'el archivo me lo envió un
amigo/primo/etc' demuestra lo fácil que es para para la chusma
criminal atacar a usuarios sin ni siquiera hacer un esfuerzo de
sofisticación en su ataque. Sólo un aumento de la cultura informática
y de la concienciación hará que el público general deje de ser una
víctima fácil.


Julio Canto
jcanto@hispasec.com


Más información:

Consumer Reports
http://www.consumerreports.org/cro/electronics-computers/computers/internet-and-other-services/net-threats-9-07/overview/0709_net_ov.htm

viernes, 10 de agosto de 2007

SPAM: del PDF al FDF

Tras la avalancha de mensajes de spam en PDF, llega una nueva variante
muy similar pero que utiliza la extensión .FDF en los archivos
adjuntos. Se trata del mismo perro con diferente collar, ya que en
realidad no utiliza el formato Forms Data Forma (FDF).

El pasado mes de junio dábamos buena cuenta de la popularización del
formato PDF como vía para enviar spam. Este viernes, desde F-Secure,
avisaban de la nueva avalancha de spam FDF que corresponde al formato
Forms Data Format, y que efectivamente está llegando en plan masivo a
los buzones de correo.

Si bien, examinando el interior de uno de esos archivos podemos
comprobar que los spammers lo único que hacen es cambiar la extensión
de .PDF a .FDF, y que el formato real del archivo sigue siendo PDF.

Esta nueva estrategia del cambio de extensión, en su lucha sin final
de burlar a los filtros antispam, aprovecha que la extensión .FDF está
también asociada a Acrobat Reader y los abre automáticamente.

Para interpretar el formato, Acrobat Reader no se deja llevar por la
extensión, sino por la cabecera que aparece en la primera línea del
archivo. El spam que está llegando, en vez de tener la cabecera del
formato Forms Data Format, que sería %FDF-1.2, contiene la cabecera
%PDF-1.5 que indica al lector que debe procesarlo como un archivo PDF.

Capturas de pantalla en: http://blog.hispasec.com/laboratorio/231

Estamos ante una treta más de los spammers que no debería plantear
mayores problemas a las soluciones antiphishing. Es más, dado que la
extensión .FDF no es tan común como .PDF, los administradores de correo
podrían llegar a plantearse introducir un sencillo filtro en los
servidores para impedir la llegada de esta nueva plaga a los buzones
de los usuarios.


Bernardo Quintero
bernardo@hispasec.com


Más información:

Se populariza el spam en formato PDF
http://www.hispasec.com/unaaldia/3167

FDF spam
http://www.f-secure.com/weblog/#00001246

jueves, 9 de agosto de 2007

Malware 2.0

Aunque no deja de ser una etiqueta de moda sin una definición clara, el concepto de la Web 2.0 hace referencia a una segunda generación de aplicaciones web dinámicas e interactivas donde el usuario tiene un mayor protagonismo y participación, frente a las webs estáticas tradicionales donde el usuario era un receptor pasivo. ¿Existe también un nueva generación de malware 2.0?

Tengo que confesar que creía que iba a ser original hablando del concepto Malware 2.0, pero una búsqueda en Google me ha sacado de mi error. Hace menos de un mes la empresa de seguridad PC Tools utilizó el término en una nota de prensa donde hablaba de una nueva generación de malware: http://www.pctools.com/news/view/id/181/

PC Tools hace referencia a características que llevamos comentando tiempo atrás en Hispasec:

* La proliferación de nuevas variantes de malware ha crecido de forma brutal.

* Se utilizan técnicas automáticas para ofuscar las variantes y dificultar la identificación por firmas.

* La estrategia actual pasa por utilizar muchas variantes en vez de un único espécimen para llamar menos la atención y dificultar una respuesta rápida por parte de la comunidad antivirus (de ahí que llevemos bastante tiempo sin ver un gusano de propagación masiva como el ILoveYou y compañía).

A continuación, como era de esperar, utiliza este argumento para vender su producto antispyware, que utiliza técnicas adicionales para no depender en exclusiva de las firmas de detección.

Aunque esas características son una realidad evidente desde hace bastante tiempo, mi idea del concepto de Malware 2.0 tiene más analogía con la Web 2.0: el uso de la web como plataforma para la distribución, personalización del malware, y uso inteligente de los datos obtenidos por parte de los usuarios para propocionar "nuevos contenidos".

Para desarrollar la idea voy a utilizar un ejemplo de ataque real, de los muchos que están sucediendo a día de hoy, destinado a los usuarios de banca electrónica:

* Los atacantes diseñan un servidor web que hospeda el código malicioso.

* Para atraer a potenciales víctimas anuncian su URL a través de spam, en foros, comentarios en blogs, etc. con cualquier excusa (bien una noticia de actualidad, curiosidades, imágenes eróticas o cualquier otro contenido potencialmente atractivo que lleven a los usuarios a visitar el servidor web de los atacantes).

* Cuando un usuario accede al sitio de los atacantes, la web comprueba la versión del navegador del visitante y, si es vulnerable, devuelve un exploit específico para su versión del navegador que provoque la descarga automática y ejecución del troyano.

* Si el usuario tiene un navegador actualizado, utiliza la ingeniería social para que el usuario descargue y ejecute por si mismo el troyano (por ejemplo, mediante un ActiveX, decirle que es un vídeo, o una utilidad que requiere con cualquier excusa).

* Este primer troyano que se descarga es un "downloader", que lo que hace es instalarse en el sistema y descargar e instalar la última versión del troyano bancario, así como sucesivas actualizaciones que pudieran aparecer en el futuro.

* El troyano "downloader" también puede personalizar la versión del troyano bancario que descarga en función del sistema. Por ejemplo, si el usuario tiene una versión de Windows en español, el "downloader" instalará en el sistema un troyano bancario diseñado específicamente para entidades españolas.

* El troyano bancario puede estar destinado a unas entidades específicas o ser más genérico. En el caso de que tenga unas entidades predefinidas, si el usuario accede a las webs de banca electrónica reconocidas por el troyano, envía los usuarios y contraseñas de acceso del usuario al servidor web para que los atacantes puedan suplantar su identidad y realizar transferencias a otras cuentas.

* En el caso de un troyano bancario más genérico e inteligente, envía a un script del servidor web de los atacantes todas las URLs por las que el usuario navegue y que comiencen por https. En el servidor web tienen un listado de URLs de bancos, si alguna de las URLs que envía el troyano corresponde con el listado, entonces el servidor web devuelve al troyano una orden concreta: redirigir al usuario a un sitio de phishing de esa entidad, modificar en local la página web de la entidad para que pida la clave de operaciones, etc.

* La información de las URLs de páginas seguras (https) por la que los usuarios navegan, y que envían al servidor web, sirve a los atacantes para diseñar nuevos ataques y actualizaciones de su troyano bancario. Por ejemplo, imaginemos que en un principio los atacantes contemplaban a Banesto, pero no al BBVA. Los usuarios que visitaban la web de Banesto eran afectados, mientras que los del BBVA no porque el servidor web no devolvía ninguna orden concreta al no tener un ataque específico preparado. Los atacantes estudian periódicamente las estadísticas de las URLs que se centralizan en su servidor, y comprueban que hay muchos usuarios infectados que visitan la web del BBVA. Entonces deciden crear una nueva versión del troyano bancario específico o una página de phishing a la que redirigir a los usuarios infectados que la próxima vez visiten la web del BBVA.

Este último punto tiene cierta analogía con servicios web 2.0 como digg.com o meneame.net, si muchos usuarios visitan una página de un banco se contabiliza en el servidor de los atacantes como votos positivos y termina por aparecer en portada (en este caso en la lista negra de entidades para las que desarrollan un ataque concreto).

Cómo podemos ver, esta nueva generación de malware utiliza la infraestructura de la web para comunicarse con los sistemas infectados de los usuarios y realimentarse con la información que estos proporcionan, aprovechando esta inteligencia colectiva para ofrecer nuevos contenidos dinámicos en función de los perfiles de los usuarios. ¿Estamos ante el malware 2.0?


Bernardo Quintero
bernardo@hispasec.com



miércoles, 8 de agosto de 2007

Antivirus: rendimiento vs. protección

El mundo de los antivirus está en crisis técnica, que no comercial,
sigue siendo un buen negocio. Pero a estas alturas a nadie escapa que
los antivirus a duras penas logran tapar parte de la ventana de riesgo
de infección a la que todo usuario de Windows se expone en Internet.
Ante este panorama cabría pensar que están triunfando los antivirus
que mayor protección ofrecen, si bien la realidad es distinta.

La gran proliferación y diversificación del malware ha puesto en jaque
a un esquema basado en tener fichados a los malos: firmas para
identificar al malware conocido, firmas genéricas para identificar
variantes de una misma familia, y heurísticas basadas en la detección
de código sospechoso.

Los malos han ganado la partida en este juego. Modifican una y otra
vez el código para que las firmas y heurísticas existentes no puedan
detectarlos, cambian la cara de sus especímenes para evitar ser
reconocidos aunque en el fondo siguen haciendo el mismo daño. Lo hacen
de forma tan masiva que los antivirus a duras penas pueden seguir el
ritmo para actualizarse, no dan a basto, están saturados. Es una
carrera sin final y nos llevan mucha ventaja.

Hay que cambiar de estrategia. Visto que actualizar firmas de forma
constante no es suficiente, los antivirus han optado por implementar
nuevas tecnologías que les permita más proactividad. El fin es poder
detectar el malware nuevo, desconocido o variante. No depender de una
firma reactiva, ser más genéricos y proactivos en la protección.

Son varias las empresas antivirus que han arriesgado en ese campo,
incorporando nuevas tecnologías y capas de seguridad al motor
antivirus tradicional, que dotan a la solución de un mayor poder de
protección. Pero no todos son ventajas a la vista del usuario, la
incorporación de este tipo de tecnologías adicionales suele conllevar
también un software más "pesado", que consume más recursos, enlentece
el sistema, tiende a dar más falsos positivos y/o termina haciendo
preguntas incomodas al usuario:

"El proceso svchost.exe intenta conectar a Internet.
¿Permitir o denegar?"

¿No se supone que el antivirus debe saber si es algo peligroso o no?,
¿por qué me pregunta a mí?. Después de una serie de pensamientos
similares, el usuario acabará por tomar alguna decisión del tipo:

.Intentará averiguar en google que es "svchost.exe" (no llegará a
ninguna conclusión, y a la segunda o tercera pregunta sobre otros
procesos desistirá en la búsqueda de la verdad)

.Permitir Todo (tarde o temprano terminará infectándose)

.Denegar Todo (dejará de funcionarle algún software legítimo)

.Desinstalar el antivirus e instalar otro que no le haga perder
tiempo con ventanitas emergentes y preguntas que no sabe contestar
(sin excluir las decisiones anteriores, el usuario suele terminar
desembocando en este punto y cambiando de antivirus)


Percepción del usuario

Ahora tenemos a un usuario con un antivirus tradicional, basado en
firmas, que no incluye tecnologías adicionales, que no enlentece el
arranque de su sistema, que no le consume mucha memoria, que no le
importuna con preguntas... tenemos a un usuario menos protegido, pero
un usuario que está teniendo una "buena experiencia" con su antivirus.

Y es que aunque teóricamente un desarrollador antivirus debe balancear
entre rendimiento y protección, la realidad es que el usuario sólo
puede percibir el rendimiento. Un usuario no sabe de tecnologías, un
usuario no puede evaluar el grado de protección que le ofrece una
solución, en la lógica de un usuario un antivirus debe protegerle de
infecciones y punto.

En los años 90 cuando un virus infectaba el ordenador se notaba de
inmediato: borraba archivos, mostraba imágenes en pantalla, etc.
Cuando un usuario se veía infectado por un virus aun teniendo
antivirus, motivaba el cambio de producto: "este antivirus no es
bueno, ha permitido que me infecte". Pero ahora el panorama es bien
diferente, el malware de hoy día está diseñado para permanecer oculto
y el mayor tiempo en los sistemas infectados, sin dar señales de vida.
Así que el usuario seguirá con la buena experiencia de su "antivirus
ligero" pese a que su sistema esté infectado. Simplemente, el usuario
no se entera.

Lo que si va a notar un usuario de inmediato es si el antivirus
interfiere en su sistema y en el trabajo diario. Esa experiencia que
si puede percibir de forma directa es la que decanta hoy día la
evaluación de un antivirus y la elección final por parte del usuario.

La balanza por parte del usuario está inclinada claramente hacia un
lado: el rendimiento. Mientras que algunos antivirus son conscientes
de ello y explotan esta visibilidad parcial por parte de los usuarios
para ganar mercado, otros siguen intentando equilibrar la balanza, o
dándole más peso a la protección, y perdiendo clientes en el camino.

¿Deben las empresas antivirus renunciar a ofrecer una mejor
protección? Evidentemente no, pero la experiencia del usuario debe ser
un objetivo igual o más importante si cabe, incluso en muchas
ocasiones tendrá mayor peso. De nada sirve diseñar el antivirus más
seguro si los usuarios no lo pueden utilizar. Para el usuario el mejor
antivirus no es el más seguro, sino el más confortable.


Algunos ejemplos

La pregunta sobre el svchost.exe me saltó ayer mientras probaba un
antivirus, y no fue la única pregunta que hizo. Es más, después de
instalarse, tras el primer reinicio del sistema, hizo un análisis
completo de todos los archivos del disco duro en segundo plano. Por la
actividad del disco duro deduje lo que estaba haciendo, y haciendo
doble click en el icono del antivirus pude confirmarlo en la ventana
del escaner.

Como medida de seguridad estaba muy bien, pero, ¿cuál es la
experiencia de un usuario común? Pues no tiene dudas, tras instalar
el antivirus el sistema se ha vuelto muy lento y apenas lo deja
trabajar. El usuario no sabe que es una acción que llevará a cabo
sólo en el primer reinicio y no en posteriores, la percepción es que
instalando el antivirus X el sistema inmediatamente se vuelve lento.

¿Por qué el antivirus no deja el análisis de todos los archivos para
más tarde, cuando detecte que el sistema lleva un tiempo en "reposo"
en vez de hacerlo justo en el inicio? Incluso podría pausar ese
análisis en segundo plano si detecta que el usuario comienza a
utilizar el ordenador, o al menos regular la velocidad y consumo de
recursos del análisis para no interferir la actividad del usuario.

Probando otros antivirus se puede notar claramente el cambio de
enfoque, acertado desde el punto de vista comercial, explotando al
máximo los conceptos de velocidad y rendimiento. Aunque en ocasiones
sea a costa de una menor protección o simplemente aplicando cierta
picaresca.

Hay un antivirus que se vende como uno de los más rápidos, para ello
tiene una opción por defecto de análisis a demanda donde no utiliza
las técnicas de heurística que más recursos consume, con las que hacen
las pruebas de velocidad. Cuando toca hacer una prueba de detección,
piden encarecidamente que se utilice la opción con la heurística más
lenta activada. Objetivo: aparecer en las evaluaciones como el más
rápido sin perder capacidad de detección. Lo logran.


Resumiendo

Demostrar que una tecnología antivirus ofrece mejor protección que
otra es complicado. Desde el punto de vista de marketing el usuario
está cansado, al fin y al cabo todos los antivirus afirman ser los
mejores, y se deja llevar por la propia experiencia o por terceros
confiables creadores de opinión.

La experiencia del usuario tiene una visibilidad muy parcial, no
puede saber que grado de protección real le ofrece un producto. Se
dejará llevar por indicadores tales como la no interferencia con su
trabajo y el rendimiento del sistema. El usuario no sabe si está
infectado o no, pero si sabe si el antivirus le molesta.

Los terceros confiables no son confiables. La dificultad que el
usuario tiene para evaluar el grado de protección de un antivirus
también se traslada a los creadores de opinión, desde foros de
Internet pasando por revistas de informática y comparativas que
tampoco están diseñadas para evaluar las nuevas tecnologías. También
tienen la resposabilidad de explicar cual es la situación actual y
las diferencias entre tecnologías, hay que formar a los usuarios.

Los evaluadores de antivirus deben evolucionar a nuevas metodologías,
siguen (seguimos) utilizando tests de los años 90 dando resultados
adulterados y penalizando a las nuevas tecnologías. Son las fuentes de
la que beben los terceros confiables, "culpables" también de la
formación en nuevas tecnologías que requieren traducir su eficacia
real en indicadores que a día de hoy simplemente no se miden.

Los desarrolladores antivirus deben reinventarse y no perder el foco
sobre el usuario. Hay productos que están incorporando tecnología
sobre tecnología en su búsqueda de minimizar la ventana de riesgo de
infección, pero convirtiéndose en un software complejo, poco
optimizado, que consume muchos recursos, y que ofrece una pobre
experiencia al usuario.

Hay que evolucionar, pero no a cualquier precio. A veces tendemos a
ofuscarnos con soluciones técnicas y olvidamos que al final un usuario,
que no es informático ni tiene nociones de seguridad, tendrá que
convivir con esas soluciones en su día a día en un PC normal, no
sobrado de recursos, que ejecuta otras aplicaciones que son realmente
las importantes para él.

Bernardo Quintero
bernardo@hispasec.com



martes, 7 de agosto de 2007

Desbordamiento de buffer a través de rmpvc en IBM AIX 4.x

Se ha descubierto una vulnerabilidad en IBM AIX que podría ser aprovechada por un atacante local para causar una denegación de servicio.

Esta vulnerabilidad se debe a un error de límite en el comando rmpvc. Un atacante podría aprovechar esto enviando argumentos port logical name especialmente manipulados, con una longitud excesiva, de más de 16 caracteres.

Se recomienda aplicar el parche APAR IY93393.
http://www-912.ibm.com/eserver/support/fixes/fcgui.jsp?whichFix=APAR&fixes=IY93393


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

IY93393: BUFFER OVERFLOW VULNERABILITY IN RMPVC
http://www-1.ibm.com/support/docview.wss?uid=isg1IY93393

lunes, 6 de agosto de 2007

Nuevos contenidos en CriptoRed (julio de 2007)

Breve resumen de las novedades producidas durante el mes de julio de
2007 en CriptoRed, la Red Temática Iberoamericana de Criptografía y
Seguridad de la Información.

** ULTIMA SEMANA PARA EL ENVÍO DE TRABAJOS AL CIBSI 2007 **
* De forma excepcional se aceptarán trabajos hasta el viernes 10 de agosto
http://www.cibsi2007.org/cfp_tercer.html

1. DOCUMENTOS NUEVOS PARA DESCARGA EN CRIPTORED (por orden alfabético)

* Análisis Forense Digital
http://www.criptored.upm.es/guiateoria/gt_m335a.htm

* Mail Gateway Linux con Filtro Antispam para Microsoft Exchange Server
http://www.criptored.upm.es/guiateoria/gt_m615a.htm

* Certificaciones en Seguridad Informática
http://www.criptored.upm.es/guiateoria/gt_m626a.htm

* Seguridad en Sistemas RFID
http://www.criptored.upm.es/guiateoria/gt_m626b.htm

* El Impacto de los Sistemas Biométricos en el Manejo de Identidades
http://www.criptored.upm.es/guiateoria/gt_m626c.htm

2. DOCUMENTOS NUEVOS PARA DESCARGA DESDE OTROS SERVIDORES

* Informe RESCATA de Alerta Virus de junio 2007 (INTECO - España)
http://alerta-antivirus.red.es/documentos/rescata/Informe_mensual_200706.pdf

* Revista Sistemas Número 101 de ACIS: Rastreando la Inseguridad (Colombia)
http://www.acis.org.co/index.php?id=974

3. CONGRESOS Y SEMINARIOS POR ORDEN CRONOLOGICO DE CELEBRACION

* Agosto 31 de 2007: 2007 International Workshop on Computational
Forensics (Manchester - Gran Bretaña)
http://www.nislab.no/events/iwcf_2007

* Septiembre 11 al 14 de 2007: II Simposio sobre Seguridad Informática
en CEDI 2007 (Zaragoza - España)
http://www.congresocedi.es/2007/si_descripcion.html

* Septiembre 17 al 19 de 2007: 2nd International Conference on Ambient
Intelligence Developments AmI.d 2007 (Riviera Francesa - Francia)
http://www.amidconference.org/

* Septiembre 21 al 23 de 2007: 21st International Conference on Systems
for Automation of Engineering and Research (Varna - Bulgaria)
http://www.criptored.upm.es/descarga/Call_for_Paper-IT-2007.zip

* Septiembre 25 al 30 de 2007: Symposium Cryptology and Information
Security en ICCMSE 2007 (Corfú - Grecia)
http://www.iccmse.org/Sessions_Minisymposia.htm

* Octubre 3 al 5 de 2007: 2nd International Workshop on Critical
Information Infrastructures Security CRITIS '07 (Málaga - España)
http://critis07.lcc.uma.es/

* Octubre 9 al 12 de 2007: 10th Information Security Conference ISC 2007
(Valparaíso - Chile)
http://www.isc07.cl/

* Octubre 16 al 19 de 2007: 7th International Symposium on
Communications and Information Technologies (Sydney - Australia)
http://www.elec.uow.edu.au/ISCIT2007/

* Octubre 24 al 26 de 2007: I Congreso Internacional de Informática y
Telecomunicaciones CIIT '07 (San Juan de Pasto - Colombia)
http://www.umariana.edu.co/ciit07/

* Noviembre 5 al 9 de 2007: 18th International Workshop on Combinatorial
Algorithms IWOCA2007 (Newcastle - Australia)
http://www.eng.newcastle.edu.au/~iwoca2007

* Noviembre 6 al 9 de 2007: V Collaborative Electronic Commerce
Technology and Research CollECTeR 2007 (Córdoba - Argentina)
http://www.collecter.org.ar/

* Noviembre 21 al 23 de 2007: Primeras Jornadas Científicas sobre RFID
(Ciudad Real - España)
http://mami.uclm.es/JornadasRFID07/

* Noviembre 25 al 28 de 2007: IV Congreso Iberoamericano de Seguridad
Informática CIBSI 2007 (Mar del Plata - Argentina)
http://www.cibsi2007.org/

* Diciembre 3 al 6 de 2007: IASK International Conference E-Activity and
Leading Technologies 2007 (Oporto - Portugal)
http://www.iask-web.org/e-alt07/e-alt2007.html

* Enero 22 al 25 de 2008: Australasian Information Security Conference
AISC 2008 (Wollongong - Australia)
http://www.eng.newcastle.edu.au/~aisc2008/

* Junio 25 al 27 de 2008: Sexto Congreso Collaborative Electronic
Commerce Technology and Research (Madrid - España)
http://www.collecter.euitt.upm.es/

* Septiembre 10 al 12 de 2008: EATIS 2008 Euro American Conference on
Telematics and Information Systems (Aracajú - Brasil)
http://eatis.org/eatis2008/

CONGRESOS ANUNCIADOS EN LA IACR:
International Association for Cryptologic Research IACR Calendar of
Events in Cryptology:
http://www.iacr.org/events/

4. CURSOS DE POSTGRADO, ESPECIALIDAD Y FORMACIÓN

Puedes encontrar los enlaces en:
http://www.criptored.upm.es/paginas/eventos.htm#Cursos

5. NOTICIAS SELECCIONADAS DEL MES DE JULIO DE 2007 (ordenado por fecha)

Ampliar las noticias:
http://www.criptored.upm.es/paginas/historico2007.htm#jul07

* Meeting OWASP Gratuito Viernes 6 de Julio 2007 en Barcelona (España)
http://www.owasp.org/index.php/Spain

* Seminario Informal de Información Cuántica del Dr. Serge Fehr en la
URJC (España)
http://homepages.cwi.nl/~fehr/

* CFP EATIS 2008 Euro American Conference on Telematics and Information
Systems (Brasil)
http://eatis.org/eatis2008/

* CFP IASK International Conference E-Activity and Leading Technologies
2007 (Portugal)
http://www.iask-web.org/e-alt07/e-alt2007.html

* Workshop Técnicas de Hacking y Forensia Informática en Congreso CIBSI
2007 (Argentina)
http://www.cibsi2007.org/prog_work.html

* CFP Revista JTAER Special Issue on RFID and Supply Chain Management
http://www.jtaer.com/

* Última semana para el envío de papers al IV Congreso Iberoamericano de
Seguridad Informática
Mar del Plata, Argentina, del 25 al 28 de noviembre de 2007
De forma excepcional se aceptarán trabajos hasta el viernes 10 de agosto
http://www.cibsi2007.org/ponformat.html

6. OTROS DATOS DE INTERES EN LA RED

* Número actual de miembros en la red: 650
(183 universidades; 236 empresas)
http://www.criptored.upm.es/paginas/particulares.htm

* Estadísticas: 54.000 visitas, con 114.000 páginas solicitadas y 31,00
GigaBytes servidos en julio de 2007 (valor estimado)
Las estadísticas del mes (AWStats) se muestran en páginas estáticas
actualizadas cada día a las 00:05 horas.
http://www.criptored.upm.es/estadisticas/awstats.www.criptored.upm.es.html


Jorge Ramió Aguirre
Coordinador de CriptoRed


Más información:

julio de 2007
http://www.criptored.upm.es/paginas/historico2007.htm#jul07