miércoles, 30 de abril de 2003

Actualización acumulativa para Microsoft BizTalk Server

Microsoft publica una actualización acumulativa para los servidores
BizTalk 2000 y 2002, que además cubre dos nuevas vulnerabilidades que
afectan a estos productos.

La primera de las nuevas vulnerabilidades solo afecta a Microsoft
BizTalk Server 2002. BizTalk Server 2002 proporciona la capacidad de
intercambiar documentos a través del protocolo HTTP. Existe un
desbordamiento de búfer en el componente empleado para recibir
documentos HTTP - el receptor HTTP - y puede resultar en que un
atacante puede llegar a ejecutar código arbitrario en el servidor
afectado.

La segunda de las vulnerabilidades afecta a ambas versiones de los
servidores BizTalk. BizTalk Server proporciona a los administradores
la posibilidad de controlar los documentos a través de un interfaz web
conocido como Document Tracking and Administration (DTA). Existe una
vulnerabilidad de inyección SQL en algunas de las páginas empleadas
por DTA que puede permitir a un atacante el envío de una URL
modificada a un usuario autorizado de DTA. Si el usuario accede a la
URL enviada por el atacante, se podrá ejecutar la consulta SQL
introducida en la URL.

Microsoft publica los siguientes parches:

Microsoft BizTalk Server 2000:
http://microsoft.com/downloads/details.aspx?FamilyId=001E93E4-0E6E-4289-AEFE-9161D2E5AF97&displaylang=en

Microsoft BizTalk Server 2002:
http://microsoft.com/downloads/details.aspx?FamilyId=A05344FE-2622-4887-AA45-3DE7C4ED3C75&displaylang=en


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin MS03-016
Cumulative Patch for BizTalk Server (815206)
http://www.microsoft.com/technet/security/bulletin/MS02-071.asp

What You Should Know About Microsoft Security Bulletin MS03-016
Security Update for Microsoft BizTalk Server
http://www.microsoft.com/security/security_bulletins/ms02-071.asp

martes, 29 de abril de 2003

Vulnerabilidades en Kerio Personal Firewall

Se han anunciado dos vulnerabilidades en Kerio Personal Firewall (KPF)
en el sistema de administración remota.

Es posible un ataque de respuesta contra el canal de
autenticación/cifrado para la administración remota. Un problema de
diseño en el mecanismo de autenticación para la administración remota
permite a un atacante responder los paquetes capturados desde una sesión
de administración remota válida para conseguir reproducir las
directivas del administrador el firewall personal.

Por otra parte, también se recoge otra vulnerabilidad de
desbordamiento de búfer explotable de forma remota en el proceso de
autenticación del administrador. Se ven afectados por estas dos
vulnerabilidades las versiones de Kerio Personal Firewall 2.1.4 y
anteriores.


Antonio Ropero
antonior@hispasec.com


Más información:

Vulnerabilities in Kerio Personal Firewall
http://www.coresecurity.com/common/showdoc.php?idx=314&idxseccion=10

lunes, 28 de abril de 2003

Virus, antivirus, y sensacionalismo mediático

A lo largo de la historia los creadores de virus han explotado los
temas de máxima actualidad en sus especímenes, bien como reclamo para
llamar la atención de los usuarios y conseguir así mayor número de
infecciones, bien para aumentar las probabilidades de que su creación
fuera motivo de noticia en los medios. Aunque la mayoría de las
compañías antivirus procuran llevar una política seria de información
sobre virus, en ocasiones también se han dejado arrastrar por el
sensacionalismo en la búsqueda de una publicidad fácil, barata y,
en la mayoría de las ocasiones, desproporcionada.

Hace unos días hemos podido asistir al último "virus mediático", en la
forma de un gusano que aprovecha como reclamo la epidemia de neumonía
atípica, simulando ser un mensaje con información relativa a esta
enfermedad para engañar a los usuarios. Bautizado por las casas
antivirus como "Coronex", se envía por e-mail utilizando diferentes
asuntos y nombres de archivo con términos como SARS (Severe Acute
Respiratory Syndrome) o Corona virus, haciendo referencia a la
enfermedad de la neumonía atípica.

El gusano nunca habría salido a la luz por su peligrosidad, ya que no
lleva a cabo ninguna acción dañina en los sistemas más allá de
intentar propagarse, ni por su nivel de propagación, hasta el momento
muy baja, tendiendo a nula según los indicadores de las propias casas
antivirus. Sin embargo, hemos podido tener conocimiento de él a través
de diversos medios, con titulares donde se mezcla la enfermedad de la
neumonía con los virus informáticos, la única verdadera razón por la
que se ha conocido.

En esta ocasión todas las noticias hacían referencia a la casa
antivirus Sophos, que se ha encargado de "advertir" sobre este nuevo
gusano. No deja de ser paradójico que en la nota publicada por Sophos
se pidiera al resto de casas antivirus responsabilidad a la hora de
informar sobre este gusano para evitar posibles confusiones. La
realidad es que ellos han sido los únicos hasta el momento que han
dedicado una nota especial a este espécimen, dando lugar a noticias
sobre un gusano que, fuera del sensacionalismo mediático, no tendría
que estar siendo motivo de noticia alguna.


Bernardo Quintero
bernardo@hispasec.com


Más información:

Coronex computer worm exploits SARS worries
http://www.sophos.com/virusinfo/articles/coronex.html

Email worm looks to capitalise on SARS fears
http://www.theage.com.au/articles/2003/04/24/1050777337688.html

New Coronex Worm Exploits SARS Worries
http://net-security.org/virus_news.php?id=220

New virus exploits SARs worries
http://www.web-user.co.uk/news/article/?afw_source_key={58772E00-9E32-48EB-8B30-0EC36078C3AE}

domingo, 27 de abril de 2003

Vulnerabilidad en algunas versiones del navegador Opera

Las versiones más antiguas del navegador para web Opera se ven
afectadas por un problema de seguridad que puede ser empleado por
un atacante para ejecutar programas en el sistema del usuario.

Si un atacante construye una página Web que incluya ciertos métodos
potencialmente peligrosos como por ejemplo ("Runtime().exec()"), puede
conseguir la ejecución de programas localizados en la carpeta system32,
con el consiguiente riesgo que le puede acarrear al visitante. Este
problema está confirmado en la versión 6.01 para Windows.

Para evitar esta vulnerabilidad se recomienda a los usuarios de este
navegador, la instalación de la última versión.


Antonio J. Román Arrebola
roman@hispasec.com


Más información:

Opera JavaScript Java Method Access Vulnerability
http://www.securityfocus.com/archive/1/317360

sábado, 26 de abril de 2003

Actualización acumulativa para Internet Explorer

Se anuncia la existencia de cuatro nuevas vulnerabilidades en el
navegador de Microsoft, la más seria de ellas permite a un atacante la
ejecución de código arbitrario en el sistema del usuario si el usuario
abre una página web maliciosa o un e-mail especialmente creado.

Microsoft publica un parche que incluye las funcionalidades de todos
los parches anteriormente publicados para Internet Explorer 5.01, 5.5
y 6.0 además de evitar estos cuatro nuevos problemas:

Desbordamiento de búfer en URLMON.DLL producido por que Internet
Explorer no comprueba de forma adecuada los parámetros de la
información recibida desde el servidor web. Un atacante podrá explotar
este problema para lograr la ejecución de código en el sistema del
usuario que visite la página.

Vulnerabilidad en el control de subida de archivos de Internet
Explorer que permite que la entrada desde un script sea pasada al
control de subida. Esta vulnerabilidad permite a un atacante
suministrar un nombre de archivo al control y subirlo de forma
automática desde el sistema del usuario al servidor web.

Vulnerabilidad en la forma en que Internet Explorer trata los archivos
de terceras partes y que puede permitir la ejecución de scripts en el
contexto de seguridad del usuario.

Fallo en el tratamiento de los diálogos modales por Internet Explorer
que ocurre debido a que no se comprueba adecuadamente un parámetro de
entrada. Este fallo permitirá a un atacante usar un script inyectado
para proporcionar acceso a archivos del ordenador del usuario.

Los parches publicados pueden descargarse desde.
http://www.microsoft.com/windows/ie/downloads/critical/813489/default.asp

Aunque este parche corrige cuatro vulnerabilidades hay que recordar
que sigue sin corregirse la anunciada en una-al-día el día 20.
También hay que aclarar que esta actualización es totalmente
independiente de la descrita en el boletín de ayer.


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin MS03-015
Cumulative Patch for Internet Explorer (813489)
http://www.microsoft.com/technet/security/bulletin/MS03-015.asp

What You Should Know About Microsoft Security Bulletin MS03-015
Security Update for Microsoft Internet Explorer
http://www.microsoft.com/security/security_bulletins/ms03-015.asp

Microsoft Knowledge Base Article - 813489
MS03-015: April, 2003, Cumulative Patch for Internet Explorer
http://support.microsoft.com/?id=813489

una-al-dia (20/04/2003) Denegación de servicios en Internet Explorer
http://www.hispasec.com/unaaldia/1638/comentar

viernes, 25 de abril de 2003

Actualización acumulativa para Outlook Express

Microsoft publica una actualización para Outlook Express para cubrir
una vulnerabilidad en el tratamiento de URLs MHTML (MIME Encapsulation
de Aggregate HTML) que podrá permitir a un atacante lograr la
ejecución de código arbitrario en el sistema atacado.

MHTML es un estándar Internet que define la estructura MIME
(Multipurpose Internet Mail Extensions) empleada para enviar contenido
HTML en mensajes e-mail.

El ataque podrá ser lanzado desde una página web maliciosa o desde un
e-mail.

La actualización se encuentra disponible en:
http://www.microsoft.com/windows/ie/downloads/critical/330994/default.asp
Esta actualización también incluye todos los parches previamente
publicados para Outlook Express


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin MS03-014
Cumulative Patch for Outlook Express (330994)
http://www.microsoft.com/technet/security/bulletin/ms03-014.asp

What You Should Know About Microsoft Security Bulletin MS03-014
Security Update for Microsoft Outlook Express
http://www.microsoft.com/security/security_bulletins/ms03-014.asp

jueves, 24 de abril de 2003

Divulgación de información sensible en Windows XP

Se ha identificado una vulnerabilidad en Windows XP, que
potencialmente puede provocar una exposición de información sensible
a usuarios locales maliciosos.

El problema proviene de una condición de carrera cuando el Service
Control Manager (SCM) recibe una señal de apagado del sistema si un
servicio no es capaz de cerrarse adecuadamente en el tiempo permitido.

Esto puede provocar que datos arbitrarios guardados en cache sean
escritos en archivos abiertos, provocando una exposición de
información sensible si un usuario malicioso accede a alguno de estos
archivos.

Este problema será corregido en Windows Server 2003. Sin embargo para
Windows XP no se publicará ningún parche que corrija el problema.


Antonio Ropero
antonior@hispasec.com



miércoles, 23 de abril de 2003

Libro gratuito: Protección de datos personales con tecnologías Microsoft

Microsoft presenta una guía, totalmente gratuita, acerca la
legislación española para la protección de los datos de carácter
personal (LOPD, ley orgánica de protección de datos de carácter
personal). Esta guía presenta, en un lenguaje sencillo y fácilmente
comprensible, cuales son los requerimientos de seguridad que establece
la ley y como se pueden utilizar los mecanismos existentes en las
plataformas de Microsoft para ajustarse a los mismos. Por otra parte,
la guía pretende acercar al lector a una ley que, hoy por hoy, es una
gran desconocida.

La ley orgánica 15/1999, de 13 de diciembre, de protección de datos de
carácter personal (LOPD) tiene como objetivo desarrollar las medidas
de protección de uno de derechos fundamentales de las personas: el
derecho a la intimidad y privacidad.

La ley define como "dato de carácter personal" a cualquier información
relativo a personas físicas que esté expresamente identificada o bien
que pueda llegar a ser identificada a partir de dichos datos. Las
medidas que establece esta ley son relativas al tratamiento que deben
recibir estos datos con la finalidad de preservar la intimidad. La
legislación española desarrolla una directiva europea, lo que
significa que en todos los países europeos existe una legislación
similar.

A pesar de que esta ley pretende proteger un derecho fundamental de
las personas, la realidad tangible es que el incumplimiento de las
directivas de la LOPD es absolutamente generalizado. Existen
básicamente dos motivos que explican este incumplimiento: en primer
lugar la poca importancia que la sociedad en general da a la intimidad
y la dificultad para identificar este derecho como uno de los derechos
fundamentales de las personas. El segundo motivo que explica la
situación actual de incumplimiento generalizado es el gran
desconocimiento que existe acerca de esta legislación.

Uno de los ejemplos clásicos para explicar este nivel de
desconocimiento es el de los dentistas. Prácticamente la totalidad de
los dentistas dispone de una base de datos informática donde tiene
registrado los datos de sus pacientes. Dentro de estos datos,
existirán algunos estrictamente administrativos como son la dirección,
forma de pago y similares. Pero probablemente también tendrá
almacenados datos de carácter médico. Aplicando la legislación de
protección de datos, estos datos referentes a la salud se consideran
como datos de máximo nivel de protección. Para cumplir a rajatabla con
la legislación, nuestro dentista debería cifrar los datos almacenados
en el ordenador, la enfermera que nos atiende en recepción no podría
dejar el ordenador 'accesible' cuando nos acompaña a la sala de espera
y el ordenador debería estar guardado bajo llave.

Otro concepto sobre los datos que habitualmente es desconocido y que
la LOPD fija muy claramente es el relativo a la propiedad de los
datos. Así la legislación indica que el propietario de los datos no
es, siguiendo el ejemplo anterior, el dentista sino que cada paciente
es propietario de sus datos. Éstos lo que hacen es dar permiso al
dentista para que almacene los datos en el soporte informático; lo
convertimos en un depositario de nuestros datos. Y esta condición de
depositario establece una serie de obligaciones, como es la obligación
de velar por que nadie pueda acceder a esos datos. Si nuestro dentista
no realiza copias de seguridad y pierde los datos, los pacientes
pueden exigirle responsabilidades por su falta de celo en la
conservación de nuestros datos.


La protección de datos personales. Soluciones en entornos Microsoft

La guía presentada por Microsoft, y que puede obtenerse en http://www.microsoft.com/spain/technet/seguridad/otros/libro_lopd.asp ,
está totalmente escrita en castellano y disponible de forma totalmente
gratuita en formato PDF (Adobe Acrobat) y LIT (Microsoft Reader) tiene
un objetivo declarado: mostrar como pueden utilizarse los mecanismos
de seguridad existente en las plataformas de Microsoft para cumplir
los requerimientos de seguridad establecidos por la ley.

Adicionalmente la guía pretende facilitar información acerca del
contenido de la ley y la importancia que tiene la misma para la
protección de nuestro derecho fundamental a la privacidad e intimidad.

Los primeros capítulos de la guía presentan los conceptos básicos
necesarios: cual es el ámbito de la ley, los diferentes tipos de datos
de carácter personal y que se entiende por intimidad y privacidad.

A continuación, se desarrollan los aspectos particulares de la
legislación española de protección de datos de carácter personal y los
diferentes estadios en que pueden encontrarse los datos, como son la
obtención de datos o su posesión y almacenamiento.

Como cualquier legislación, el incumplimiento de la LOPD puede derivar
en la imposición de determinadas sanciones. La guía también nos
explica las posibles infracciones y las consecuencias que las mismas
pueden ocasionarnos.

La segunda parte de la guía se centra en las medidas de seguridad
existente en las plataformas de Microsoft (Windows 2000 y Windows XP)
y como utilizarlas para poder ajustarse a los diferentes
requerimientos que establece la LOPD: auditoría, autorización,
autentificación, control de acceso, realización de copias de
seguridad, cifrado de datos, etc. Todo esto sin olvidar la importancia
que tiene en todo el proceso el disponer de una política de seguridad
que se ajuste a esta legislación.

Como anexos, encontramos un plan de adaptación al reglamento de
medidas de seguridad de los archivos automatizados que contienen datos
de carácter personal, el texto íntegro de la ley y el reglamento de
medidas de seguridad. Por último, nos facilita una colección de
recursos, fuentes y documentación relativos a la seguridad
informática.

Debemos felicitar a Microsoft por tomar la iniciativa de publicar esta
guía. Cualquier acción que facilite un mayor conocimiento acerca de la
protección de un derecho básico como es nuestra intimidad es realmente
digna de reconocimiento.


Xavier Caballé
xavi@hispasec.com



martes, 22 de abril de 2003

Debilidad en protocolo de autenticación NTLM

Todas las versiones de Windows utilizan el protocolo SMB para los
servicios de compartición de archivos e impresoras. Cuando un cliente
se conecta a un recurso de la red, se utiliza la autenticación NTLM
para enviar las credenciales de usuario incluyendo la contraseña. Un
servidor SMB malévolo puede utilizar esta información para
autenticarse en el cliente, llegando a poder obtener pleno control
sobre los recursos compartidos en el cliente (incluyendo, por ejemplo,
a C$).

SMB (Server Message Block) es el protocolo utilizado para la
compartición de recursos (carpeta compartida, una impresora, un puerto
serie o mecanismos de comunicación como pueden ser los named pipes)
entre máquinas basadas en los sistemas operativos Windows. Para las
funciones de autenticación de usuarios se utiliza otro protocolo, NTLM
(NT Lan Manager).

El proceso de autenticación NTLM es, de forma resumida, el siguiente:
cuando el cliente se conecta a un servidor, éste responde enviando un
testigo generado aleatoriamente (el desafío). El cliente aplica una
función hash a este testigo utilizando la contraseña del usuario y
envía el resultado al servidor. En el momento en que éste recibe la
respuesta, comprueba su validez verificando que coincide con el
resultado de aplicar al desafío enviado la misma función hash con la
contraseña almacenada en su base de datos. Gracias a este método, se
puede verificar la identidad del usuario sin que sea necesario que la
contraseña circule por la red.

Por diseño, en el momento en que un cliente accede a un recurso
compartido realiza un intento de autenticación utilizando las
credenciales del usuario activo. Si estas credenciales no son
aceptadas por el servidor, la máquina cliente muestra al usuario una
ventada para que introduzca el usuario y contraseña para acceder al
recurso compartido.

Es precisamente esta característica, la de intentar autenticarse
automáticamente con las credenciales del usuario activo, la que puede
permitir a un servidor malicioso obtener la información de las
credenciales del usuario.

Como ejemplo de ataque, el atacante envía a la víctima un mensaje HTML
que contiene un objeto que reside en un recurso compartido del
servidor malévolo (SM1). Al visualizar este mensaje, la máquina
cliente (C1) intentará conectar con el recurso compartido.

El servidor malévolo (SM1) cuando recibe la petición de desafío, en
lugar de enviar éste lo que hace es una petición de conexión a un
recurso compartido a una estación cliente (C2). Este cliente malévolo,
C2, responde enviando una petición al servidor SMB de la víctima
(SC1).

El servidor SC1 envía su desafío a la máquina cliente del atacante,
C2. A continuación, C2, envía el desafío al servidor malévolo (SM1) y
éste a su vez lo envía a la máquina cliente (C1).

El cliente C1 recibe el desafío y aplica la función hash con su
contraseña. A continuación devuelve la respuesta al servidor malévolo
(SM1).

El servidor malévolo (SM1) reenvía esta respuesta a la máquina cliente
C2. Éste último, C2, redirecciona esta respuesta hacia el servidor SMB
de la víctima (SC1). En este punto, SC1 recibe la respuesta y la
considera como válida.

Como resultado de este galimatías, la máquina cliente del atacante
(C2) dispone de una conexión de red validada contra la máquina cliente
(C1).

Resumiendo y simplificando: el ataque consiste en aprovechar una
petición de autorización de acceso a un recurso compartido en un
servidor malévolo para construir y validar una conexión autenticada
contra la máquina que está realizando la petición.

Como puede comprobarse, el ataque es relativamente complejo y para
poder ser aprovechado es preciso disponer de un buen conocimiento del
funcionamiento de los protocolos SMB y NTLM.

No obstante, se tiene constancia de la existencia de pruebas de
concepto que muestran la viabilidad de este ataque. Todas las
versiones de Windows son vulnerables, incluyendo Windows 9x/ME
(vulnerable, aunque no se ha verificado), Windows NT 4 (vulnerable,
aunque no se ha verificado), Windows 2000 Professional/Server
(verificado), Windows XP (verificado) y Windows 2003 Server
(vulnerable, aunque no se ha verificado).


¿Es posible evitar este ataque?

La respuesta es afirmativa. Este ataque sólo puede utilizarse en los
sistemas que utilicen la autenticación NTLM. Aquellos que utilicen la
autenticación NTLM2 no son vulnerables. NTLMv2 está desactivado por
defecto, pero está disponible en NT 4.0 (a partir del Service Pack 4)
y versiones posteriores. NTLMv2 dispone de mecanismos adicionales de
seguridad mediante la utilización de claves de sesión únicas.

El ataque tampoco puede utilizarse cuando se utiliza la autenticación
Kerberos, que es el mecanismo de autenticación utilizado por defecto
en el Active Directory (Windows 2000 y posterior).


Xavier Caballé
xavi@hispasec.com



lunes, 21 de abril de 2003

Ataques de denegación de servicio... a través de correo postal

Alan Ralsky, el rey del spam, está recibiendo un autentico ataque
distribuido de denegación de servicio que consiste en inundar su correo
postal. Un estudio muestra como estos ataques pueden automatizarse.

Para aquellos que no lo conozcan, Alan Ralsky es uno de los personajes más
prolíficos en el envío de correo basura a través de Internet, con una larga
trayectoria a sus espaldas, iniciada en 1997, y un sinfín de denuncias de
todo tipo. Ralsky ha utilizado todo tipo de estratagemas para conseguir
utilizar la infraestructura de los grandes proveedores de conectividad para
el envío de spam.

El pasado mes de diciembre de 2002, Alan Ralsky concedió una entrevista
donde ridiculizaba y se reía de toda la comunidad contraria a la existencia
del spam y que valora la intimidad de su buzón de correo. Se quejaba, por
ejemplo, del coste que le suponía tener toda su infraestructura en China
ante la imposibilidad de utilizar las empresas norteamericanas. En esa
entrevista cometió el error de comentar que su casa estaba situada en una
población del estado norteamericano de Michigan.

Esta entrevista fue reproducida en slashdot.org y uno de los lectores
encontró la dirección postal del domicilio del spammer. De forma totalmente
espontánea, otros lectores utilizaron esta dirección para suscribir al
spammer a catálogos comerciales, revista de anuncios, panfletos, solicitudes
para recibir información, etc... Otros fueron más allá y le enviaron
directamente basura (en el sentido literal de la palabra).

En la edición del 15 de abril de la revista Crypto-Gram, Bruce Schneier
comenta este hecho. Dejando de banda la ironía que supone inundar al rey del
spam con su propia basura (aunque en forma de átomos y no de bytes),
Schneier aprovecha para comentar una investigación realizada donde se
demuestra la posibilidad de automatizar este tipo de ataques.

El estudio, "Defending against an internet-based attack on the physical
world", describe una situación parecida a la que ha sufrido el rey del spam.
Cualquier persona con nociones de programación en un lenguaje de scripts
como Perl o Python puede utilizar los recursos existentes en la actualidad
para ejecutar un ataque de este tipo, automatizando la solicitud de envío de
propaganda por correo postal contra cualquier dirección. Todo esto sin
olvidar que una única persona podría conseguir el mismo efecto que ha tenido
en el buzón de Alan Ralsky la acción no coordinada de los miles de lectores
de slashdot.


Xavier Caballé
xavi@hispasec.com



domingo, 20 de abril de 2003

Denegación de servicios en Internet Explorer

La última versión del navegador de Microsoft se bloquea al visualizar
una página web con una etiqueta OBJECT especialmente construida.
Cuando un usuario visualiza la página que provoca el DoS se produce
un error y fuerza al cierre de todas las sesiones de Internet
Explorer abiertas.

Como prueba de concepto, el siguiente código HTML reproduce el
problema. Basta con guardarlo con extensión .htm y abrir el
archivo para comprobar el efecto que produce en Internet Explorer.

>>>

data="#"
width="100%" height="100%"
type="text/x-scriptlet"
VIEWASTEXT>


<<<

De momento no existe solución al problema, si bien se espera que en
breve Microsoft ofrezca algún parche al respecto. Mientras tanto,
otras medidas de prevención podrían pasar por detectarlo a nivel de
filtros de contenidos, e incluso antivirus, que cada vez más
incorporan detección de exploits tanto a nivel servidor como
cliente.


Bernardo Quintero
bernardo@hispasec.com


Más información:

Microsoft Internet Explorer Malformed Object Tag Denial of Service
Vulnerability
http://www.securityfocus.com/bid/7373/info/

sábado, 19 de abril de 2003

Desbordamiento de búfer en la gestión de mensajes en el núcleo de Windows (NT 4.0, 2000 y XP)

Se ha descubierto un desbordamiento de memoria en el soporte de
depuración de Windows NT 4.0, 2000 y XP. Un atacante que logre
aprovecharse de esta vulnerabilidad puede conseguir el completo control
sobre el sistema vulnerable.

El núcleo del sistema operativo es el centro del sistema operativo. Este
centro ofrece a los programas de aplicación servicios para acceder a los
recursos existentes, como son la memoria, el procesador, los
dispositivos (pantalla, teclado, ratón, disco duro...). Así mismo,
incluye funciones para gestionar cualquier situación de error.

Se ha descubierto que los núcleos de los sistemas operativos Windows NT
4.0, 2000 y XP contienen un error en la forma en que se tratan
determinados mensajes que son enviados al depurador. Este error puede
provocar una vulnerabilidad de seguridad.

Concretando más, la función LpcRequestWaitReplyPort(), que es utilizada
por el núcleo del sistema operativo, confía en que un proceso que se
ejecuta en el espacio de memoria de usuario facilitará correctamente el
tamaño de un mensaje devuelto al núcleo.

Mediante la utilización de esta vulnerabilidad, un atacante puede
ejecutar código en el anillo 0 (el mismo anillo dónde se ejecuta el
núcleo del sistema operativo y en donde no se aplica la separación de
procesos ni la protección de memoria). Esto permite saltarse cualquier
mecanismo de seguridad existente y un acceso ilimitado a cualquier
recurso del sistema. El código que se ejecuta en este anillo dispone
incluso de más privilegios que el usuario administrador de la máquina.

Esta vulnerabilidad no es explotable de forma remota. Únicamente puede
ser aprovechada por un atacante que disponga de la capacidad de
conectarse al sistema, ya sea en una sesión interactiva (utilizando el
teclado y monitor del ordenador) o a través de una sesión de terminal.

Microsoft ha publicado una serie de parches para los diferentes sistemas
operativos afectados por este problema: Windows NT 4.0, Windows NT 4.0
Server (edición servidor de terminales), Windows 2000 y Windows XP
(ediciones de 32- y 64-bit).

Un aviso para los usuarios de Windows 2000. Según se desprende de un
mensaje en la lista NTBugTraq (ver la URL en "Más información"), este
parche incluye nuevas versiones de algunos archivos de sistema no
indicados en el articulo de la KB de Microsoft.

Concretamente, dentro del parche se incluye la misma versión de
NTDLL.DLL incluida en parche para el problema relacionado con WebDAV
(MS03-007). Cuando se instalaba esta versión de NTDLL.DLL, en
circunstancias muy concretas, algunos sistemas Windows 2000 no podían
arrancar. El archivo NTDLL.DLL incluido en este parche tiene seis bytes
diferentes respecto a la versión incluida en MS03-007. No obstante,
Microsoft no informa de si estos ligeros cambios son suficientes para
solucionar los problemas de compatibilidad descritos previamente. En
consecuencia, antes de aplicar este parche en sistemas críticos,
aconsejamos probarlo previamente en un entorno de pruebas.


Xavier Caballé
xavi@hispasec.com



viernes, 18 de abril de 2003

Nueva vulnerabilidad en Snort

Detectada una vulnerabilidad que permitiría a un atacante remoto
ejecutar código con los mismos privilegios que Snort, típicamente
root.

Snort es uno de los IDS (Sistema de Detección de Intrusiones) más
extendidos. Distribuido de forma gratuita como Open Source, Snort
puede detectar múltiples ataques basándose en el análisis de los
paquetes según unas bases de datos de firmas de ataques conocidos
y reglas genéricas.

Ya el pasado 8 de marzo nos hacíamos eco en "una-al-día" del
desbordamiento de buffer en el módulo que realiza el preproceso de
RPCs, que también permitía su explotación para ejecutar código
arbitrario de forma remota.

En esta ocasión el módulo afectado es el preprocesador stream4,
que permite a Snort ensamblar paquetes TCP antes de ser analizados,
función muy útil en la detección de ataques especialmente diseñados
para evadir a los IDS. Los detalles de la vulnerabilidad, junto a
un exploit a modo de prueba de concepto, pueden ser encontrados en
el aviso de Core.

Las versiones de Snort afectadas comprenden desde la 1.8 hasta las
anteriores a la 2.0, versión esta última donde se ha corregido el
problema (http://www.snort.org/dl/snort-2.0.0.tar.gz). Los usuarios
de cajas negras (appliances) como Network Sensor de SourceFire,
SecurNet PDS y otras, que utilizan entre otros componentes Snort,
deberían contactar con el soporte o distribuidor de las mismas para
verificar si es necesario actualizarlas.


Bernardo Quintero
bernardo@hispasec.com


Más información:

Desbordamiento de búfer en Snort
http://www.hispasec.com/unaaldia/1595

Snort(TM) Advisory: Integer Overflow in Stream4
http://www.snort.org/advisories/snort-2003-04-16-1.txt

Multiple Vulnerabilities in Snort Preprocessors
http://www.cert.org/advisories/CA-2003-13.html

Snort TCP Stream Reassembly Integer Overflow Vulnerability
http://www.coresecurity.com/common/showdoc.php?idx=313&idxseccion=10

jueves, 17 de abril de 2003

Desbordamiento entero en rutinas Sun RPC XDR

Gran parte de los sistemas que utilizan el sistema XDR definido por SUN
son susceptibles de un ataque de desbordamiento entero que permite, bajo
circunstancias propicias, que un atacante remoto mate servicios e
incluso llegue a ejecutar código arbitrario en el servidor.

Las primitivas XDR (External Data Representation) son rutinas que
permiten la representación uniforme de tipos de datos sin tener en
cuenta la arquitectura del sistema por su traducción a una
representación externa, y viceversa.

La vulnerabilidad radica en la función "xdrmem_getbytes()", en la que
existe un desbordamiento entero. Un desbordamiento entero es aquel en el
que una variable "entera" se sale de su rango numérico y "da la vuelta".
Por ejemplo, si la variable es un entero de 8 bits, sin signo, los
valores posibles van del 0 al 255 (2^8-1). Si la variable, en un momento
determinado, contiene el valor 253 y se le suma 10, el resultado no es
263 sino 7. Asimismo, si la variable contiene el valor 3 y le restamos
5, el resultado no es -2 sino 254.

Dependiendo del uso concreto que se haga de "xdrmem_getbytes()", estos
desbordamientos enteros pueden ser ocasionar la caída del servicio o
desbordamientos de búferes que den opción a la ejecución de código
arbitrario en el servidor. Según las circunstancias, también se puede
exponer información sensible al atacante, en el datagrama de respuesta a
su petición.

La vulnerabilidad afecta a las librerías SUN originales y a sus
derivados, como las utilizadas en los *BSD y en la GLIBC (Linux). Dado
que estas librerías son usadas por infinidad de aplicaciones, será
necesario:

a) Actualizar las librerías, tanto estáticas como dinámicas.
b) Parar y relanzar las aplicaciones que carguen las librerías de forma
dinámica, para que tomen la nueva versión.
c) Reenlazar las aplicaciones que carguen las librerías de forma
estática, para que tomen la nueva versión.

Dada la gran difusión de esta tecnología y su penetración en infinidad
de aplicaciones de muy bajo nivel (por ejemplo, la GLIBC), se recomienda
seguir con detalle y cuidado las instrucciones de actualización de cada
fabricante.


Jesús Cea Avión
jcea@hispasec.com


Más información:

CERT® Advisory CA-2003-10 Integer overflow in Sun RPC XDR library
routines
http://www.cert.org/advisories/CA-2003-10.html

XDR Integer Overflow
http://www.eeye.com/html/Research/Advisories/AD20030318.html

Overflow de Enteros en Rutinas de Bibliotecas XDR de SUN RPC
http://www.unam-cert.unam.mx/Boletines/Boletines2003/boletin-UNAM-CERT-2003-010.html

Integer overflow in Sun RPC XDR library routines
http://www.kb.cert.org/vuls/id/516825

01/08/2002 - Desbordamiento de búfer remoto en Sun RPC
http://www.hispasec.com/unaaldia/1376

miércoles, 16 de abril de 2003

Vulnerabilidades criptográficas en Kerberos v4

El diseño criptográfico de Kerberos versión 4 permite ataques como
suplantación de personalidad y acceso no autorizado a recursos en red.
Estos ataques pueden destruir por completo la infraestructura Kerberos
de una organización.

Kerberos es un protocolo que permite la centralización de los procesos
de autenticación dentro de una red, estando especialmente pensado para
ser utilizado en redes heterogéneas y de grandes proporciones.
Básicamente permite que un cliente autentificado por el servidor central
pueda utilizar su credencial ("ticket") para acceder a servicios en red.

Los ataques concretos son:

* Un atacante que controle una clave compartida "cross-realm" puede
hacerse pasar por cualquier entidad en el "realm" remoto. Ello
incluye suplantar o acceder como administrador al KDC, violando con
ello toda la seguridad de la red.

* Este ataque es transitivo, pudiendo comprometer también "realms"
accesibles desde el "realm" remoto, y propagar el ataque a otras
redes.

* Existe un segundo ataque similar que no requiere el control de
una clave compartida "cross-realm". Es más difícil, pero realizable.

* Adicionalmente, un atacante puede hacerse pasar por cualquier
usuario o servidor que utilice claves kbr4 triple-DES, siempre
que tenga acceso al tráfico de red de la víctima.

Se trata de problemas de diseño del protocolo, y no pueden soslayarse
dentro de un entorno Kerberos v4. La recomendación es deshabilitar por
completo el soporte de Kerberos v4, prestando servicio exclusivamente a
través de Kerberos v5, que no es susceptible a estos problemas. Ello
incluye, también, el eliminar cualquier servicio de adaptación Kerberos
v4<->v5 que pudiese existir en la red.

Adicionalmente, si está usando Kerberos v5, asegúrese de emplear una
versión actualizada. Las versiones anteriores a Marzo de 2003 contienen
desbordamientos de búfer documentados y solucionados.


Jesús Cea Avión
jcea@hispasec.com


Más información:

N-057: Cryptographic weaknesses in Kerberos v4 protocol
http://www.ciac.org/ciac/bulletins/n-057.shtml

Topic: Cryptographic weaknesses in Kerberos v4 protocol
http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-004-krb4.txt

Kerberos cryptographic implementation flaws
http://www.secunia.com/advisories/8319/

Buffer overrun and underrun in principal name handling
http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2003-005-buf.txt


martes, 15 de abril de 2003

Vulnerabilidad de tratamiento de archivos PS/PDF en KDE

Se ha anunciado la existencia de una vulnerabilidad en KDE por el procesamiento realizado por Ghostscript para la visualización de archivos PostScript (PS) y PDF de forma que puede llegar a permitir a un atacante la ejecución de comandos arbitrarios.

La vulnerabilidad, que afecta a las versiones KDE 2 y KDE 3 hasta la KDE 3.1.1, permitirá a un atacante la ejecución de cualquier comando incluido en un archivo PostScript o PDF maliciosamente creado. Los comandos se ejecutarán bajo los privilegios de la cuenta de usuario de la víctima cuando esta el archivo o cuando navegue a un directorio que contenga el archivo malicioso y se tenga activa la previsualización de documentos. El ataque podrá lanzarse de forma remota mediante el envío del archivo en un e-mail o como parte de una página web.

Las aplicaciones afectadas se han corregido en KDE 3.0.5b y KDE 3.1.1a.
KDE 3.0.5b puede descargarse desde:
http://download.kde.org/stable/3.0.5b/
KDE 3.1.1a está disponible en:
http://download.kde.org/stable/3.1.1a/

La actualización del paquete KDEGraphics y asociados a la versión 2.2.2-6.11 también corrige el problema.


Antonio Ropero
antonior@hispasec.com


Más información:

KDE Security Advisory: PS/PDF file handling vulnerability
http://www.kde.org/info/security/advisory-20030409-1.txt

lunes, 14 de abril de 2003

Acceso a archivos arbitrarios en Oracle E-Business Suite

Se ha anunciado la existencia de una vulnerabilidad en Oracle
E-Business Suite que permitirá a los usuarios remotos la recuperación
de cualquier archivo que pueda ser leído por las cuentas "oracle" o
"applmgr".

El problema existe debido a una debilidad en el protocolo empleado
para las comunicaciones con Oracle Applications FND File Server. Para
explotar esta vulnerabilidad los usuarios necesitan acceso al servidor
Concurrent Manager a través de TNS Listener (también conocido como
SQL*Net y Net8).

Se ven afectadas por este problema las versiones:
Oracle Applications 10.7
Oracle Applications 11.0
Oracle E-Business Suite 11i

Oracle ha publicado los siguientes parches disponibles desde
http://metalink.oracle.com/

Oracle E-Business Suite 11i
Parche 2782945

Oracle Applications 11.0
Parche 2782950

Oracle Applications 10.7
No hay parche disponible.


Antonio Ropero
antonior@hispasec.com


Más información:

Oracle Security Alert 53
Report Review Agent (RRA/FNDFS) Vulnerability in Oracle E-Business Suite
http://otn.oracle.com/deploy/security/pdf/2003alert53.pdf

domingo, 13 de abril de 2003

Actualización para Microsoft Proxy Server 2.0 e y Microsoft ISA Server

Microsoft publica una actualización de sus productos Proxy Server 2.0 e ISA Server para evitar un problema de denegación de servicios en estos servidores.

El problema radica en un fallo en el servicio Winsock Proxy de Microsoft Proxy Server 2.0 y en el servicio Microsoft Firewall de ISA Server 2000, que podrá permitir a un atacante de la red interna provocar que el servidor deje de responder a cualquier petición interna o externa.

Cuando el servidor recibe un paquete maliciosamente creado se alcanzará el 100% de consumo de CPU lo que hará que deje de responder a cualquier petición.

Las actualizaciones pueden descargarse desde las siguientes direcciones:

Proxy Server 2.0:
http://microsoft.com/downloads/details.aspx?FamilyId=C81688B7-20FB-45EB-BAFD-031A0D2923E6&displaylang=en
ISA Server (inglés):
http://microsoft.com/downloads/details.aspx?FamilyId=3C43FAD2-A888-4603-84B7-1053C8663436&displaylang=en
ISA Server (español):
http://microsoft.com/downloads/details.aspx?FamilyId=3C43FAD2-A888-4603-84B7-1053C8663436&displaylang=es


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin MS03-012
Flaw In Winsock Proxy Service And ISA Firewall Service Can Cause Denial Of Service
http://www.microsoft.com/technet/security/bulletin/ms03-012.asp

Denial of Service in Microsoft Proxy Server 2.0 and Internet Security and Acceleration Server 2000
http://www.idefense.com/advisory/04.09.03.txt

sábado, 12 de abril de 2003

Protección de Windows 2000 Server y/o Internet Information Server

Microsoft publica un conjunto de guías y herramientas para ayudar a los
administradores de sistemas en la comprensión e implementación de los
mecanismos de seguridad existentes en el sistema operativo Windows 2000
Server.

En los últimos meses Microsoft está hablando del concepto "trustworthy
computing" o informática de confianza. Se trata de uno de esos conceptos
difusos y poco explicados que Microsoft frecuentemente utiliza.
Básicamente el objetivo es poder ofrecer unos productos que puedan
considerarse como "seguros en su diseño, seguros en su configuración por
defecto, seguros en el momento de desplegarlos y seguros en los
mecanismos de comunicaciones utilizados". El lector de "una-al-día" sabe
que estos objetivos todavía están lejos de alcanzarse.

Para ayudar a los administradores de sistemas en la planificación de
todos los procesos y decisiones que son necesarios tomar para obtener un
nivel adecuado de seguridad y garantizar que dicho nivel se mantenga,
Microsoft ha publicado un conjunto de guías y herramientas que cubren
todo el abanico de opciones de seguridad existentes en Windows 2000
Server así como en Internet Information Server 5.0.

* Securing Windows 2000 Server

La primera guía está dividida en once capítulos que tratan los
siguientes temas:

1. Introducción a la seguridad de Windows 2000 Server.
2. Discusión de los componentes de seguridad necesarios para realizar un
análisis de la organización.
3. Metodologías para el análisis de la seguridad.
4. Aplicando disciplinas de gestión de riesgos de seguridad.
5. Protección de la infraestructura de dominio.
6. Fortalecimiento de Windows 2000 Server.
7. Fortalecimiento de los roles específicos para servidores-
8. Gestión de parches.
9. Auditoría y detección de intrusiones.
10. Respuesta a incidencias de seguridad.
11. Conclusiones.

* IIS Lockdown

El objetivo de esta herramienta es desactivar todas aquellas
características disponibles en IIS que no son utilizadas o que pueden
afectar a la seguridad del sistema.

* URLScan

Esta es una herramienta de seguridad muy potente que permite aplicar
mecanismos para la restricción de las peticiones HTTP tratadas por el
servidor web, de forma que es posible bloquear posibles peticiones
malévolas como las utilizadas en ataques de desbordamiento de búfer.

* Lista de verificación de la seguridad de IIS

Este documento incluye algunas recomendaciones y buenas prácticas para
la protección de los servidores web basados en IIS y Windows 2000 con el
objetivo de disponer de la configuración más segura.



Xavier Caballé
xavi@hispasec.com



viernes, 11 de abril de 2003

Vulnerabilidad crítica para todas las versiones de Windows

Una vulnerabilidad en la Máquina Virtual de Microsoft, encargada de
dar soporte a Java, permite a un atacante construir applets para
ejecutar código arbitrario de forma remota. Se recomienda a todos
los usuarios de Windows la actualización inmediata.

Todas las versiones de la Máquina Virtual de Microsoft anteriores
a la 3810 son vulnerables. Para comprobar la versión instalada
en nuestro sistema será necesario ejecutar el comando JVIEW en
una ventana DOS.

Desde el menú Inicio, opción Ejecutar, y teclear:

command (en el caso de Windows 95, 98, 98SE o Millenium)

o

cmd (en el caso de Windows NT, 2000 o XP)

Se abrirá una ventana con el símbolo de sistema, y tendremos que
introducir el comando "jview" (sin las comillas).

Nos mostrará varias líneas, los últimos 4 dígitos de la primera
línea nos indicará la versión de nuestra Máquina Virtual.

>>>

C:\>JVIEW
Cargador de línea de comandos de Microsoft (R) para Java Versión 4.79.2435
Copyright (C) Microsoft Corp 1996-2000. Todos los derechos reservados.

<<<

En este caso nuestra versión sería la 2435, inferior a la 3810 donde
se encuentra corregida la vulnerabilidad, y por tanto necesitaremos
actualizar de inmediato. Si al ejecutar el comando recibimos un error
indicando que ese programa no existe, es que no tendremos instalada
la Máquina Virtual.

Para proceder a la actualización automática basta con acceder al
servicio Windows Update, desde el menú de Inicio, o a través de la
dirección http://windowsupdate.microsoft.com, escoger "Buscar
actualizaciones" e instalar los items que aparezcan en
"Actualizaciones críticas y Service Packs", entre los que se
encontrará la corrección a la mencionada vulnerabilidad.

La vulnerabilidad se encuentra en un fallo del verificador de códigos
bytes en la implementación de Microsoft, una de las capas de
seguridad que contempla los applets de Java, encargado de validar
la seguridad de los applets a través de varias comprobaciones para
evitar situaciones potenciales de riesgo.

Este fallo permitiría a un atacante diseñar un applet de Java para
ejecutar código arbitrario en el sistema del usuario que lo
visualice, bien a través de una página web, bien haciéndolo llegar
a través de un e-mail. Microsoft considera la vulnerabilidad, y su
actualización, crítica, tanto por la repercusión en la seguridad
como por el ámbito de sistemas que abarca, ya que la Máquina Virtual
se distribuye junto a Internet Explorer y se encuentra presente
en prácticamente todos sus sistemas operativos Win32.


Bernardo Quintero
bernardo@hispasec.com


Más información:

Microsoft Security Bulletin MS03-011
http://www.microsoft.com/technet/security/bulletin/MS03-011.asp

jueves, 10 de abril de 2003

Actualización urgente de SAMBA

Las versiones de SAMBA anteriores a la 2.2.8a son susceptibles a un
ataque remoto que permite la ejecución de código arbitrario en el
servidor, con privilegios de administrador o "root".

Samba es una implementación Unix "Open Source" del protocolo
SMB/NetBIOS, utilizada para la compartición de archivos e impresora en
entornos Windows. Gracias a este programa, se puede lograr que máquinas
Unix y Windows convivan amigablemente en una red local, compartiendo
recursos comunes. Incluso es factible utilizar un servidor Samba para,
por ejemplo, actuar como controlador de un dominio Microsoft Windows.

La vulnerabilidad, de la que apenas se conocen detalles, afecta a todas
las versiones de SAMBA anteriores a 2.2.8a (incluyendo la serie 2.0.*),
pero no afecta a las versiones 3.0.*, actualmente en desarrollo.

La recomendación es actualizar a SAMBA 2.2.8a con la mayor premura
posible. Al parecer los scripts de ataque ya se están distribuyendo por
Internet.

Esta es la segunda actualización urgente de SAMBA en tres semanas, pero
fue solucionado apenas una hora después de tener constancia del
problema.


Jesús Cea Avión
jcea@hispasec.com


Más información:

Samba Exploit Discovered, Fixed
http://developers.slashdot.org/article.pl?sid=03/04/07/2135238

SuSE Security Announcement: samba (SuSE-SA:2003:025)
http://www.suse.com/de/security/2003_025_samba.html

DSA 280-1: samba
http://www.debian.org/security/2003/dsa-280

Topic: security issue in samba ports
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SN-03:01.asc

SAMBA
http://samba.org/samba/samba.html

miércoles, 9 de abril de 2003

SETI@home: la vulnerabilidad está aquí dentro

Los clientes del proyecto SETI@home se ven afectados por una vulnerabilidad remota que puede permitir a cualquier atacante tomar el control de cualquier ordenador que participe en este sistema de informática distribuida.

Se ha descubierto una vulnerabilidad de desbordamiento de búfer en el cliente SETI@home en el tratamiento de las respuestas del servidor. De forma que bastará enviar una cadena de gran longitud seguida del carácter de nueva línea (‘\n’) al cliente para provocar el desbordamiento. El servidor principal de SETI@home (shserver2.ssl.berkeley.edu) también se ha visto afectado por un problema similar que podría haber permitido a un atacante no solo tomar el control del servidor sino de los más de 4 millones de colaboradores del proyecto.

SETI@home es un conocido proyecto de informática distribuida creado por Universidad de Berkeley y el instituto SETI, en el que en la actualidad participan más de 4,3 millones de usuarios colaborando, de forma conjunta y coordinada, para analizar las señales captadas por los radiotelescopios en busca de señales de inteligencia extraterrestre.

Se recomienda a todos los usuarios del cliente (o salvapantallas) de SETI@home actualicen a la nueva versión 3.08 publicada para corregir esta vulnerabilidad y que se encuentra disponible desde:
http://setiathome.berkeley.edu/download.html.


Antonio Ropero
antonior@hispasec.com


Más información:

SETI@home
http://setiathome.berkeley.edu/

SETI@home Clients Information Leakage and Buffer Overflow Vulnerabilities
http://www.net-security.org/vuln.php?id=2594

martes, 8 de abril de 2003

Nuevo Curso : Sistemas IDS y análisis forense de incidentes

Instituto Seguridad Internet (ISI) e Hispasec presentan un nuevo curso
único en España: "Sistemas IDS y análisis forense de incidentes". Si
la oferta de formación de calidad en seguridad es escasa en nuestro
país, lo es aun más en los temas tratados en este curso.

El curso está dirigido a fuerzas policiales, peritos judiciales,
administradores y auditores de seguridad, encargados de la función de
la detección de intrusiones tanto en tiempo real como el posterior
análisis forense. También se dirige a los arquitectos de seguridad, ya
que la implantación y diseño de políticas de seguridad requiere una
infraestructura de respuesta a incidentes.

Después de la realización del curso los asistentes habrán obtenido una
amplia visión de como planificar de manera correcta la detección de
intrusiones, como analizar un sistema que ha sufrido un ataque y serán
capaces de organizar correctamente un plan de respuesta ante
incidentes de seguridad.

El curso se plantea de forma práctica, los asistentes realizan
ejemplos reales de protección y análisis de equipos que han sufrido
intrusiones. Cada aspecto se plantea inicialmente desde el lado del
intruso, una vez comprendido, se mostrará su posible solución, y lo
que es más importante, las medidas preventivas necesarias para
evitarlo.

El curso se compone de lo siguientes siete capítulos:

Introducción
Técnicas de detección de intrusiones
Tipos de IDS
Análisis forense - Captura de la evidencia
Análisis de la evidencia volátil
Análisis de la información de disco
Análisis de sistemas cliente.
Análisis de programas sospechosos

La duración del curso es de 20 Horas divididas en cuatro sesiones de
5 horas que se celebrarán en Madrid, cada alumno dispone de un sistema
Windows-Linux y se entrega un manual del curso en castellano así como
un CD con las herramientas utilizadas y documentación adicional.

Durante la primera edición del curso los antiguos alumnos de
ISI - Hispasec se beneficiarán de un descuento del 20% sobre los
derechos de inscripción.

La Información detallada sobre los contenidos, programa, fechas, y un
formulario de inscripción se encuentran en la dirección:

http://www.hispasec.com/directorio/servicios/formacion/IDSanalisisforense





lunes, 7 de abril de 2003

Desbordamiento de búfer en Solaris a través de lpq

Se ha encontrado una vulnerabilidad de desbordamiento de búfer en lpq,
una aplicación del sistema Sun Solaris. Un atacante local que explote
esta vulnerabilidad podrá conseguir privilegios de root.

El comando lpq se emplea para mostrar los contenidos de la cola de
impresión, por defecto instalado como suid root. Como no se han
implementado comprobaciones de límites validos en los datos
proporcionados por los usuarios puede permitir al atacante crear
un desbordamiento de búfer. Este problema permitirá realizar un ataque
de denegación de servicio e incluso lograr la ejecución de código con
privilegios de root.

Sun ha publicado las siguientes actualizaciones para evitar el problema:
Para Solaris 2.6
http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=106235&rev=12
Para Solaris 2.6 x86
http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=106236&rev=12

Para Solaris 7
http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=107115&rev=12
Para Solaris 7 x86
http://sunsolve.sun.com/pub-cgi/findPatch.pl?patchId=107116&rev=12


Antonio Ropero
antonior@hispasec.com


Más información:

Solaris Security Vulnerability due to a Buffer Overflow in lpq(1B)
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert/52443

Solaris lpq Stack Buffer Overflow Vulnerability
http://www.nsfocus.com/english/homepage/sa2003-02.htm

domingo, 6 de abril de 2003

Security-Enhanced Linux (SELinux)

Security Enhanced Linux, SELinux, es una colección de parches que
modifican el núcleo del sistema operativo Linux, fortaleciendo los
mecanismos de control de acceso y forzando la ejecución de los procesos
dentro de un entorno con los mínimos privilegios necesarios.

Modelos de control de acceso en Unix

Tradicionalmente los sistemas Unix han utilizado el modelo de control de
acceso discrecional (Discretionary Access Control, DAC) en el que un
usuario tiene un completo control sobre los objetos que le pertenecen y
los programas que ejecuta. Así mismo, el programa ejecutado por un usuario
tendrá los mismos permisos de ese usuario que lo está ejecutando.

Esto implica que la seguridad del sistema depende de las aplicaciones que
se están ejecutando y, por tanto, cuando se produce una vulnerabilidad de
seguridad en una aplicación, ésta afecta a todos los objetos a los que el
usuario tiene acceso. Así, si la aplicación es ejecutada por root, el
atacante puede obtener los máximos privilegios en la máquina,
comprometiendo la seguridad global del sistema.

Otro modelo de control de acceso es el denominado control de acceso
obligatorio (Mandatory Access Control, MAC), donde existe una política de
seguridad definida por el administrador y que los usuarios no pueden
modificar. Esta política va más allá de establecer propietarios de
archivos sino que fija "contextos", en donde se indica cuando un objeto
puede acceder a otro objeto. Este modelo de control de acceso puede
aumentar el nivel de seguridad, especialmente cuando se establece como
base de la política definida que no se permite cualquier operación no
expresamente autorizada.

La implementación de este modelo de seguridad para todo un sistema puede
ser una tarea muy tediosa. En teoría deben definirse reglas para cualquier
usuario que utiliza cualquier programa que accede a cualquier objeto del
sistema. Para evitar tener que llegar a este detalle de definición, algo
que fácilmente se convertiría en un monstruo inmanejable, se utiliza el
concepto de control de acceso basado en roles (Role-Based Access Control,
RBAC). Bajo este modelo, el administrador define una serie de roles y
asigna a los usuarios en los diferentes roles que corresponden a su
perfil.

Como ejemplo, el usuario de un programa únicamente necesita disponer de
permisos para leer y escribir los archivos utilizados por esa aplicación
concreta, pero nada más. Otros usuarios es posible que necesiten permisos
para poder leer archivos, pero no modificarlos. Cada uno de estos usuarios
se asignará a diferentes roles.


SELinux

La primera versión de SELinux se remonta a finales del año 2000 cuando la
NSA (Agencia Nacional de Seguridad de los Estados Unidos). El objetivo del
mismo es, por un lado, demostrar la posibilidad de implementar el modelo
de seguridad de control de acceso obligatorio (MDAC) y el control de
acceso basado en roles (RBAC) en entorno Linux. Como segundo objetivo, el
hacer frente a la eventualidad de que los sistemas operativos "trusted"
comerciales dejaran de estar disponibles.

SELinux puede considerarse como una implementación práctica del modelo de
seguridad de control de acceso obligatorio basado en el núcleo del sistema
operativo Linux. Un administrador de un sistema SELinux tiene la
posibilidad de configurar una política donde se define los archivos a que
tiene acceso cada programa.

Para poder realizar esto, SELinux implementa un mecanismo para establecer
en cada archivo y proceso el contexto en el que está siendo utilizado.
Mediante la utilización de un módulo del sistema operativo, es posible
establecer reglas para permitir o denegar el acceso a cualquier archivo
del sistema (utilizando el concepto de archivo de Unix, lo que incluye a
los dispositivos, archivos...).

El sistema operativo dispone de un proceso servidor de seguridad, que se
ejecuta como parte del núcleo, que decide en base a la política de
seguridad definida por el administrador, si algo (un proceso o un usuario)
dispone de permiso para acceder a un objeto (archivo, dispositivo...).
Este mecanismo de control se denomina Type Enforcement (TE).

Así, ante una incidencia de seguridad como puede ser un desbordamiento de
búfer en un proceso ejecutado por root, el atacante sólo podrá acceder a
los archivos para los cuales el proceso vulnerable esté autorizado por la
política del sistema. No tendrá ningún efecto sobre el resto de archivos u
objetos del sistema.

SELinux también permite implementar un modelo adicional de seguridad
(Multi-Level Security, MLS) en el que además de lo indicado hasta ahora es
posible, para cada objeto, una capa de seguridad (como "altamente
secreta", "secreta", "confidencial" y "sin restricción"). En este modelo,
a los mecanismos descritos anteriormente se añade la restricción de que
únicamente aquellos procesos y usuarios situados en la misma capa (o una
capa superior) puede acceder a los objetos, pero nunca al revés. Así un
usuario o un proceso de la capa "confidencial" puede acceder a la
información "confidencial" y "sin restricción", pero nunca a la
información marcada como "secreta" o "altamente secreta".


Instalación de SELinux

SELinux hasta ahora se ha venido distribuyendo como una colección de
parches para el código fuente del núcleo del sistema operativo. No
obstante, recientemente se ha cambiado la arquitectura, pasando a ser un
módulo que utiliza los enganches de seguridad facilitados por el Linux
Security Module (LSM).

Por tanto, como paso previo a la instalación de SELinux debe instalarse el
sistema operativo Linux. Actualmente, SELinux da soporte únicamente a Red
Hat Linux (versión 7.3), aunque se sabe por la experiencia de diversos
usuarios que funciona con otras distribuciones (Debian, SuSE,
Mandrake...).

Los requerimientos para la instalación del sistema operativo Linux son:
utilizar sistema de archivos ext2 o ext3, instalar las herramientas
necesarias para compilar el núcleo e instalar los diversos componentes que
deberá ejecutar el servidor (como BIND, Apache, Samba...). Se recomienda
no instalar el soporte gráfico.

Cuando tengamos operativo el sistema operativo puede procederse a la
instalación de SELinux. Actualmente existen versiones para las versiones
2.4 y 2.5 del núcleo del sistema operativo. La distribución actual de
SELinux incluye:

* El código fuente del núcleo estándar de Linux, con los parches de
SELinux ya aplicados.
* El soporte para Linux Security Modules (LSM)
* El soporte de SELinux para LSM
* Programas para la administración de SELinux y las políticas de seguridad
* Diversos ejemplos de políticas de seguridad
* Diversas utilidades para sustituir algunas de las utilidades estándar
del sistema (cp, find, id, ls, mkdir...) de forma que reconozcan las
políticas.

En este punto, sólo queda compilar el núcleo modificado de Linux
distribuido en el paquete SELinux, utilizando cualquiera de los métodos
habituales para recompilar el núcleo del sistema operativo. Deberemos
seleccionar las opciones "NSA SELinux Support" y "NSA SELinux Development
Support".


Utilizando SELinux

Cuando ya tenemos SELinux funcionando, la mayoría de herramientas estándar
del sistema, como ps o ls, disponen de una nueva opción --context que nos
permite determinar el contexto de seguridad en el que se están ejecutando:

[root@test /]# ps -e --context
PID SID CONTEXT COMMAND
1 7 system_u:system_r:init_t init
2 1 system_u:system_r:kernel_t [keventd]
3 1 system_u:system_r:kernel_t [kapmd]
...
2728 323 root:user_r:user_t -bash
2920 323 root:user_r:user_t ps -e --context
[root@test /]#

Como podemos ver hay dos columnas adicionales: SID (identificador de
seguridad) y el contexto de seguridad, compuesto por el usuario asociado,
el rol y su tipo. El usuario system_u se asigna automáticamente a todos
los archivos existentes antes de la instalación de SELinux.

Como durante la instalación de SELinux hemos configurado el núcleo con el
SELinux Development Support, el sistema está funcionando en modalidad
permisiva. Esto significa que en lugar de bloquear aquellas funciones no
permitidas por la política de seguridad simplemente las registra (por
defecto en /var/log/messages).

Utilizando el mandato avc_toggle podemos cambiar la modalidad para que el
sistema bloquee cualquier función no expresamente autorizada:

[root@test /] # tail /var/log/messages
. el contenido del registro de actividad ...

[root@test /] # avc_toggle
enforcing
[root@test /] # tail /var/log/messages
tail: /var/log/messages: Permission denied
[root@test /] # avc_toggle
avc_toggle: Permission denied
[root@test /] #

Es decir, una vez aplicada la política ningún usuario no autorizado puede
modificarla, ni tan siquiera el propio root.

La restauración de la modalidad permisiva sólo puede realizarla bajo el
rol de sysadm_r:

[root@test /] # newrole -r sysadm_r
Authenticating root.
Password: root@password
[root@test /] # avc_toggle
permissive
[root@test /] # tail /var/log/messages
. el contenido del registro de actividad ...

Ahora en el registro de actividad del sistema podemos ver que han quedado
registrados los intentos que hemos realizado y han sido denegados por la
política.


Definición de la política

Explicar como configurar la política de SELinux es algo que se escapa al
alcance de este boletín, pero facilitamos algunos datos básicos. Los
lectores interesados encontrarán información más detallada en la
documentación incluida dentro de SELinux.

Los archivos de la política residen en el directorio
/etc/security/selinux/src. Dentro de este directorio encontramos el
archivo users que contiene la relación de usuarios y las definiciones de
roles.

En el subdirectorio file_contexts se definen las plantillas de política
para los diversos tipos de archivos existentes en el sistema. Por ejemplo:

/etc/security/selinux/src/file_context/program/ntpd.fc

/var/lib/ntp(/.*)? system_u:object_r:var_lib_ntp_t
/etc/ntp.conf system_u:object_r:etc_ntp_t
/usr/sbin/ntpd system_u:object_r:ntpd_exec_t
/var/log/ntpstats(/.*)? system_u:object_r:var_log_ntp_t
/var/log/ntpd.* system_u:object_r:var_log_ntp_t
/etc/cron.(daily|weekly)/ntp-simple system_u:object_r:ntpd_exec_t

La primera columna es una expresión regular para los nombres de archivos
sobre los que se aplica la política y la segunda columna es el contexto
sobre el que se aplica la política.

En el directorio /etc/security/selinix/src/domains se establecen las TE
(Type Enformcement) para los objetos del sistema. La forma habitual de
realizar esta definición es mediante el lenguaje de marcas m4.


Obtener SELinux

La versión actual de SELinux da soporte a las versiones 2.4.* y 2.5.* del
núcleo de Linux y está disponible en forma de modulo para LSM (que también
está incluido en la distribución). También incluye versiones modificadas
de algunos paquetes y utilidades estándares del sistema GNU/Linux. Entre
otras utilidades encontramos fileutils (para poder visualizar o
especificar el contexto de seguridad), findutils (para poder buscar
archivos en base a su contexto de seguridad), logrotate (modificado para
conservar el contexto de seguridad de los archivos de registro de
actividad rotados), procps (para visualización del contexto de seguridad
de los procesos), openssh (modificado para establecer el contexto de
seguridad en los procesos de usuario), tar (para almacenar el contexto de
seguridad en los archivos .tar, etc..


Xavier Caballé
xavi@hispasec.com



sábado, 5 de abril de 2003

La consola de recuperación de Windows 2000 en XP. ¿Vulnerabilidad o sensacionalismo?

Hace unas pocas semanas, a raíz de una noticia publicada en un weblog,
muchos medios de información publicaron cosas como "la mejor forma de
"crackear" un Windows es utilizando el propio Windows" o "Hachear Windows
XP es cosa de niños". ¿Titulares buscando el sensacionalismo o reflejo
fiel de la realidad?

A mediados de febrero se publicó en el weblog de Brian Levingston
(briansbuzz.com) un artículo donde se explicaba que era posible utilizar
la consola de recuperación de Windows para obtener privilegios de
administrador en un ordenador que utilizara Windows XP. El método consiste
en arrancar la máquina utilizando un CD-ROM de Windows 2000 e iniciar la
consola de recuperación (tecla F8 durante la inicialización del sistema
operativo).

En teoría, para poder acceder sin contraseña a la línea de órdenes del
sistema operativo desde la consola de recuperación es necesario editar el
registro del sistema y añadir una clave. Así es como lo explica Microsoft
en un articulo de la knowledge base.

Entonces la pregunta es, ¿porqué arrancando con un CD de Windows 2000 se
puede acceder al disco? Simplemente, Windows 2000 no es capaz de acceder
al registro de Windows XP (¡afortunadamente!... si accediera posiblemente
el remedio sería mucho peor que cualquier enfermedad) por lo que deduce
que la instalación de Windows está dañada. Como tampoco puede acceder a la
SAM, como último recurso de recuperación permite acceder directamente al
disco desde el indicador de la línea de mandatos.

Esto es precisamente lo que se desea. Si por alguna razón el sistema no
puede arrancar y queda en un estado tan deplorable, la consola de
recuperación debe permitir realizar los cambios necesarios para que el
sistema vuelva a ser operativo. Incluso si para hacer estos cambios es
necesaria la intervención manual del administrador, con las limitaciones
propias de la administración en un entorno tan limitado como este.

Por tanto, todo esto no puede considerarse como una vulnerabilidad de
seguridad. Todo lo contrario, es una función muy útil en aquellas
situaciones en que la máquina se niega a iniciar.

La realidad es que, desde esta línea de órdenes, poca cosa podemos hacer.
Cierto, podemos copiar o borrar archivos, pero no podemos realizar ningún
cambio significativo en la configuración del sistema. Por otra parte, si
los archivos sensibles están cifrados (porque todos nosotros ciframos los
archivos con información sensible, ¿no?) no servirán de nada al
'atacante', ya que incluso pudiendo acceder al archivo, su contenido será
totalmente ininteligible.

Por otra parte, si tenemos acceso al disco duro, ¿para qué complicarnos la
vida accediendo mediante la consola de recuperación? Es mucho más rápido y
cómodo utilizar un disquete de MS-DOS con programas para acceder a las
particiones NTFS. Evidentemente sin necesidad de ninguna contraseña. Estos
disquetes de MS-DOS pueden dar soporte a la conexión de red, de forma que
no sea necesario copiarlos manualmente.

Pero si queremos hacerlo cómodamente, podemos instalar ese disco duro como
unidad secundaria en otra máquina. De esta forma, podemos hacer cualquier
cosa con él, utilizando todos los programas que habitualmente utilizamos
para navegar por el disco duro.

Moraleja de la historia. Desde el momento en que un intruso ha obtenido
acceso físico a nuestro sistema, todo lo que haga está fuera de nuestro
control. Cualquier medida de protección aplicada, como son las contraseñas
de acceso, puede ser sorteada de una forma u otra. De hecho, la única
medida que nos queda para preservar la información de los discos es el
cifrado de los datos. Cualquier otra explicación que se quiera dar a esta
presunta vulnerabilidad no es otra cosa que marear la perdiz.


Xavier Caballé
xavi@hispasec.com



viernes, 4 de abril de 2003

Actualización urgente a Apache 2.0.45

Las versiones de Apache 2.0.* anteriores a la 2.0.45 son susceptibles a
un grave ataque de denegación de servicio.

Apache es el servidor web más popular del mundo, disponible en código
fuente y para infinidad de plataformas, incluyendo UNIX, Microsoft
Windows, OS/2 y Novell NetWare.

La fundación Apache ha publicado un preaviso para que todos los usuarios
de la serie 2.0.* del servidor Apache actualicen con urgencia a la
versión 2.0.45.

Aparte de problemas menores, la versión 2.0.45 soluciona dos problemas
de seguridad importantes:

* Ataque de denegación de servicio sobre todas las plataformas.

La fundación Apache proporcionará los detalles el próximo 8 de Abril,
y advierte a sus usuarios que actualicen sus sistemas antes de
dicha fecha.

* Filtración de descriptores de ficheros a los CGIs, potencialmente
maliciosos.

Es de destacar que la versión 2.0.45 contiene todavía un ataque de
denegación de servicio que afecta a la versión OS/2 y será solucionado
en la versión 2.0.46 (que aún no existe). Pero el equipo Apache
considera que las vulnerabilidades descubiertas son lo bastante
importantes como para publicar la versión 2.0.45 aún conteniendo
vulnerabilidades conocidas, aunque sean para una plataforma minoritaria.


Jesús Cea Avión
jcea@hispasec.com


Más información:

Apache 2.0.45 Released
http://www.apache.org/dist/httpd/Announcement2.html

[HACK]Problema de seguridad en Apache. ¿Todos vulnerables?
http://mailman.argo.es/pipermail/hacking/2003-April/001473.html

Unknown vulnerability in filestat.c for Apache running on OS2, versions
2.0 through 2.0.45, allows unknown attackers to cause a denial of
service, possibly related to an error in identifying invalid files.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0134

Apache HTTP Server Source Code Distributions
http://www.apache.org/dist/httpd/

The Apache HTTP Server Project
http://httpd.apache.org/

jueves, 3 de abril de 2003

Actualización de Windows XP para redes Wi-Fi

Microsoft publica una actualización destinada a mejorar la
implementación de la conexión a redes inalámbricas en Windows XP.

La actualización ofrece soporte para Wireless Protected Access (WPA),
un nuevo estándar para la seguridad en entornos wireless desarrollado
por la Wi-Fi Alliance.

El WPA está destinado a reemplazar a WEP (Wired Equivalent Privacy),
el estándar actual, al ofrecer métodos más robostos para el cifrado y
la autenticación.

La actualización puede descargarse desde:
En español:
http://download.microsoft.com/download/d/9/1/d916d6f8-5823-4b11-8e88-7702d4b5456a/Q815485_WXP_SP2_x86_ESN.exe

En Inglés:
http://download.microsoft.com/download/c/c/2/cc2aae3a-da13-4a9a-b3d9-802b0e7c877c/Q815485_WXP_SP2_x86_ENU.exe


Antonio Ropero
antonior@hispasec.com


Más información:

Overview of the WPA Wireless Security Update in Windows XP
http://support.microsoft.com/?kbid=815485

Windows XP Support Patch for Wireless Protected Access - Español
http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=009d8425-ce2b-47a4-abec-274845dc9e91

Wi-Fi Alliance
http://www.wifialliance.org/

una-al-dia (19/11/2002) Seguridad de las redes inalámbricas: Wardriving y Warchalking
http://www.hispasec.com/unaaldia/1486

miércoles, 2 de abril de 2003

Desbordamiento de búfer en Apple QuickTime Player

Recientemente se ha descubierto una vulnerabilidad de desbordamiento
de búfer que afecta al reproductor Apple QuickTime Player versiones
5.x y 6.0.

Este ataque, que se puede explotar remotamente, puede producirse cuando
QuickTime Player trata URLs de gran longitud. Si un atacante
suministra una URL de más de 400 caracteres provocará un
desbordamiento de búfer, que podrá ser empleado para lograr la
ejecución de código arbitrario con los privilegios del usuario.

Es posible explotar esta vulnerabilidad a través de una página web o
un email incluyendo una URL "quicktime://".

Como contramedida a los usuarios de Apple QuickTime Player, se recomienda
eliminar QuickTime como visualizador automático del navegador o eliminar
del registro la llave "HKEY_CLASSES_ROOT/quicktime", esto puede prevenir
la explotación automática a través de páginas web.

Desde Hispasec se recomienda actualizar a Apple QuickTime Player 6.1,
versión que puede ser obtenida desde la dirección:
http://www.apple.com/quicktime/download/

Solamente se ven afectadas las versiones de Apple Quicktime Player que
corren sobre sistemas Windows .


Antonio J. Román Arrebola
roman@hispasec.com


Más información:

Buffer Overflow in Windows QuickTime Player
http://www.idefense.com/advisory/03.31.03.txt

martes, 1 de abril de 2003

Tests antivirus para comprobar la protección del e-mail

Hispasec pone a disposición de todos los usuarios dos tests para
comprobar el correcto funcionamiento de la protección antivirus
del correo electrónico. El primero de ellos nos indicará la
correcta instalación y buen funcionamiento del antivirus, mientras
que el segundo determinará la capacidad de detección proactiva
para identificar gusanos que explotan vulnerabilidades conocidas.

* Test EICAR (comprobación de funcionamiento)

El test consiste en enviar un mensaje con el archivo EICAR como
adjunto a la dirección de correo electrónico del usuario y comprobar
la reacción del antivirus a su llegada.

El EICAR Standard Anti-Virus Test File es un archivo reconocido por
los productos antivirus pero NO es un virus real ni provoca ningún
efecto dañino; es totalmente inofensivo. Se trata de un pequeño
programa para DOS de 68 bytes, totalmente operativo, que se utiliza
como estándar para comprobar el correcto funcionamiento de los
antivirus sin necesidad de utilizar muestras de virus reales. Al
ejecutar el archivo EICAR, se visualiza el siguiente mensaje:
"EICAR-STANDARD-ANTIVIRUS-TEST-FILE".

Los productos antivirus que estén bien configurados y cuenten con
protección para el correo entrante deberán alertar al usuario
durante la recepción del mensaje que contiene el archivo EICAR. En
tal caso, el resultado del test será óptimo y demostrará el
correcto funcionamiento de su programa antivirus.

Los antivirus que no alerten de la llegada del mensaje no estarán
configurados para comprobar el correo de entrada. Posiblemente,
podrán detectar el archivo cuando el usuario trate de ejecutarlo o
intente guardarlo en alguna unidad. Para comprobar esta posibilidad,
le recomendamos que guarde el archivo adjunto en una carpeta a la
espera de la alerta del programa antivirus.

En el caso de existir antivirus perimetrales, como por ejemplo en
el servidor de correo, puede que el archivo EICAR no llegue al
usuario, ya que habrá sido detectado y eliminado en el perímetro
por los antivirus instalados en los servidores, lo que será
indicador de su buen funcionamiento.

Este test tan sólo comprueba el correcto funcionamiento del
antivirus, en ningún caso será un indicador de la calidad del
mismo.

ADVERTENCIA: Aunque se puede ejecutar el archivo EICAR sin ningún
reparo, le recomendamos que NO lo haga. Cabe la posibilidad de que
algún individuo sin escrúpulos renombre un virus real para que se
confunda con el EICAR y lo distribuya aprovechando la coyuntura de
este test. Los usuarios que quieran comprobar el funcionamiento de
su programa antivirus mediante la ejecución del archivo EICAR
deberán extremar las precauciones, asegurándose de que ejecutan el
archivo original proporcionado por Hispasec, enviado exclusivamente
a petición del propietario de la dirección de correo.

Para evitar el uso indiscriminado del test, y la redirección de los
mismos a direcciones de terceros, primero se enviará un mensaje
de confirmación conteniendo un enlace. Al pinchar ese enlace se
redireccionará a una página web que automáticamente enviará a su
dirección el mensaje con el test.

Test EICAR
http://www2.hispasec.com/tests/eicar/


* Test VEMLIE (detección proactiva, muy recomendado)

Una buena parte de los gusanos que mayor número de infecciones han
causado en los últimos tiempos explotan una vulnerabilidad conocida
de Internet Explorer a través de la cual es posible forzar la
ejecución automática de un binario adjunto en un mensaje de correo
(.EML). Por ejemplo es la técnica utilizada por gusanos como Klez,
que sigue manteniendo el número 1 en las listas de detección por
e-mail. Para lograrlo modifica la cabecera MIME que hace referencia
al archivo de forma que simula ser un formato confiable. Esto
provoca que Internet Explorer lo abra sin preguntar al usuario.
Esta vulnerabilidad es heredada por los clientes de correo Outlook
y Outlook Express, ya que utilizan el componente de Internet Explorer
para visualizar los mensajes HTML.

Este test permite verificar que: o bien su antivirus detecta
correctamente los emails maliciosos que intentan explotar esta
vulnerabilidad, o que tiene su versión de Internet Explorer
correctamente actualizada y no se encuentra afectado por la
vulnerabilidad.

La solución óptima será que su antivirus detecte que el mensaje
enviado intenta explotar la vulnerabilidad. De manera independiente
a si tiene una versión de Internet Explorer actualizada, esta
funcionalidad de su antivirus le permitirá detectar de forma
proactiva nuevos gusanos que intenten infectar los sistemas
aprovechando esta misma vulnerabilidad (desde el primer minuto,
antes de que sean reconocidos por los laboratorios antivirus, y
sin necesidad de esperar la actualización para su producto).
También le prevendrá de ataques directos que utilizan esta
vulnerabilidad para ejecutar troyanos y backdoors de forma
automática

Los antivirus que detectan la explotación de vulnerabilidades
suelen identificar estos mensajes utilizando el prefijo "Exploit",
seguido del nombre de la vulnerabilidad, que en este caso concreto
recibe, entre otros, los nombres de "MIME" e "iFrame".

Si su antivirus detecta el mensaje del test VEMLIE, el resultado
será el óptimo. Si por el contrario no lo hace, pero no se ejecuta
de forma automática (sin que el usuario abra o ejecute el archivo
adjunto), su sistema no será vulnerable, si bien debe conocer que
su antivirus tampoco detecta este tipo de mensajes maliciosos,
y no puede prevenirle de forma proactiva contra ataques dirigidos
o gusanos que utilicen esta vulnerabilidad. Por último, si su
antivirus no ha detectado nada y el archivo adjunto se ejecuta
automáticamente, aparecerá una ventana de DOS, o Internet Explorer
con una página web, que le informará de que su sistema es vulnerable
y los pasos para corregir el problema.

El adjunto que acompaña a este test, t.bat, no debe ser detectado
por los antivirus. Se trata de un pequeño archivo de proceso por
lotes que se ejecutará de forma automática al visualizar el
mensaje en el caso de que el sistema del usuario sea vulnerable.
Su única misión consiste en informar sobre la vulnerabilidad e
intentar abrir una ventana de Internet Explorer para que se
dirija a una página web en Hispasec donde se informa de los pasos
a seguir para corregir dicha vulnerabilidad.

Los usuarios no deben de ejecutar directamente el archivo t.bat,
ya que la redirección a la página web donde se informa a los
usuarios que son vulnerables será utilizada adicionalmente como
contador con fines estadísticos (% de usuarios vulnerables).

Al igual que ocurre con el test EICAR, en el caso de existir
antivirus perimetrales, como por ejemplo en el servidor de correo,
puede que el mensaje del test VEMLIE no llegue íntegro al usuario,
ya que habrá sido detectado y desinfectado o eliminado en el
perímetro por los antivirus instalados en los servidores, lo que
será indicador de su buen funcionamiento.

Para evitar el uso indiscriminado del test, y la redirección de los
mismos a direcciones de terceros, primero se enviará un mensaje
de confirmación conteniendo un enlace. Al pinchar ese enlace se
redireccionará a una página web que automáticamente enviará a su
dirección el mensaje con el test.

Test VEMLIE
http://www2.hispasec.com/tests/vemlie/


Bernardo Quintero
bernardo@hispasec.com