viernes, 28 de febrero de 2003

Nueva forma de spam a través de mensajes emergentes de Windows

Se popularizan algunas nuevas herramientas para el envío de spam
utilizando el servicio Messenger de Windows. Explicamos como funcionan y
que medidas de protección debemos utilizar.

El servicio Messenger (no confundir con el Microsoft Messenger o el MSN
Messenger ni con ningún programa de navegación web o lectura de correo
electrónico) es un servicio de los sistemas operativos de la familia
Windows que implementa un sencillo sistema de envío de mensajes y avisos
entre las máquinas conectadas en la red local.

Inicialmente el servicio Messenger fue incorporado en los primeros
sistemas operativos de red basados en NetBIOS (OS/2 y las primeras
versiones de Windows) y estaba pensado para permitir a los administradores
de red enviar notificaciones a los usuarios, por ejemplo cuando era
preciso detener el servidor. Otros programas que utilizan este servicio de
forma legitima son los controladores de impresión (para avisar de la
finalización de un trabajo de impresión), los sistemas de alimentación
ininterrumpida, los antivirus y otros programas que necesitan un mecanismo
simple de notificación de un evento.

Cuando el servicio está activo (y en todas las versiones de Windows lo
está en la configuración por defecto), cualquier usuario puede enviar un
mensaje emergente a otra estación de la red ejecutando, en una ventana DOS, la orden NET SEND con los parámetros adecuados. Además, los programas disponen de la API NetMessageBufferSend para automatizar el envío de estos mensajes.

Durante los últimos meses del año pasado empezaron a circular diversos programas pensados para utilizar este servicio de Windows como un nuevo
método para la difusión masiva de mensajes comerciales. Algunos de estos
programas han llegado, incluso, a ser anunciados en televisión como una
nueva herramienta de márketing en Internet. Estos programas están pensados para automatizar el envío masivo de los mensajes, sin que el spammer tenga que preocuparse de otra cosa que escribir el texto del spam.


Como nos llegan estos mensajes

Los mensajes emergentes utilizan el protocolo NetBIOS, por lo que cuando
circulan por una red TCP/IP utilizan los puertos udp/137 y tcp/139. Este
es el mecanismo habitual de transmisión para los mensajes enviados
mediante un NET SEND o la API NetMessageBufferSend.

No obstante, los programas de automatización de este tipo de spam utilizan
un método diferente de envío mediante el servicio RPC (Remote Procedure
Call, Llamada de procedimiento remoto) de NetBIOS, que está asociado al
puerto udp/135.

Los mensajes se presentan en una ventana de Windows, con el título
"Messenger Service" o "Mensajería de Windows", con el texto del mensaje y
un botón Aceptar. Al pulsar el botón, la ventana se cierra.


Medidas de protección

En primer lugar es importante indicar que el simple hecho de recibir un
mensaje de este tipo no sólo muestra que estamos expuestos a la recepción
de este tipo de publicidad. En realidad no está revelando un importante
problema de seguridad en nuestra máquina, ya que está admitiendo
conexiones NetBIOS desde Internet.

Por tanto, la primera acción a realizar consiste en verificar las medidas
de seguridad perimetrales existentes, a nivel de cortafuegos y routers.
Debemos comprobar que se está bloqueando cualquier tráfico con origen
Internet y destino la red interna que utilice cualquiera de los puertos
asociados a NetBIOS: udp/135, udp/137-139, udp 445, tcp/137- 139 y
tcp/445.

Los usuarios de cortafuegos personales deben verificar, adicionalmente,
los permisos asignados a los ejecutables utilizados en las comunicaciones
RPC (svchost.exe y services.exe) para comprobar que no se permite la
recepción de tráfico NetBIOS con origen Internet y destino hacia estos
archivos ejecutables.

No existe ninguna razón que justifique la utilización de NetBIOS como
método de acceso remoto a la red corporativa de una empresa o a los
ordenadores de un usuario particular.

Como medida de protección adicional, podemos desactivar el servicio en las
máquinas para evitar la recepción de estos mensajes emergentes, siguiendo
estas instrucciones.

* Windows 95/98/ME

A diferencia de los sistemas operativos derivados de Windows NT, la
única forma de desactivar la recepción de estos mensajes pasa por
desactivar completamente el soporte de NetBIOS.

Si no desea desactivar este soporte, la única opción que tenemos es
la instalación de un cortafuegos personal que bloquee el tráfico
NetBIOS que provenga de Internet.

Acceder al Panel de Control ("Mi PC", "Panel de control") y hacer
doble clic sobre el icono "Red".

En la pestaña "Configuración" hacer clic en el botón "Compartir
archivos e impresoras...". Verificar que las dos opciones, "Permitir
que otros usuarios tengan acceso a mis archivos" y "Permitir que
otros usuarios impriman con mis impresoras" están desactivadas.
Pulsar Aceptar.

De nuevo en la pestaña "Configuración", seleccionar el protocolo
TPC/IP asociado a la tarjeta de red o al módem/router que utilizamos
para la conexión a Internet. Hacer clic en el botón "Propiedades".

En la ventana "Propiedades de TCP/IP", seleccionar la pestaña
"Enlaces" y deseleccionar la opción "Cliente para redes Microsoft".
Pulsar en "Aceptar" y "Aceptar".

A continuación será preciso reiniciar la máquina.


* Windows NT 4.0

Ir a "Inicio", "Configuración", "Panel de control". Hacer doble clic
sobre el icono "Servicios".

Buscar el servicio "Mensajería" ("Messenger" en las versiones en
inglés). Si está iniciado, pulsar el botón "Detener" para detenerlo.
A continuación pulsar el botón "Inicio..." y cambiar el tipo de
inicio del servicio: "Deshabilitado". Pulsar en "Aceptar" y en
"Cerrar".


* Windows 2000

Ir a "Inicio", "Programas", "Herramientas administrativas" y
"Servicios".

Buscar el servicio "Mensajería" y seleccionarlo. Pulsar el botón
derecho del ratón y seleccionar "Propiedades". Pulsar el botón
"Detener" para detener el servicio.

A continuación, cambiar el tipo de inicio a "Deshabilitado". Pulsar
en "Aceptar" y cerrar la ventana de servicios.


* Windows XP

Ir a "Inicio", "Panel de Control". Entrar en el apartado de
"Rendimiento y mantenimiento" y hacer doble clic sobre el icono
"Servicios".

Buscar el servicio "Mensajería" y seleccionarlo. Pulsar el botón
derecho del ratón y seleccionar "Propiedades". Pulsar el botón
"Detener" para detener el servicio.

A continuación, cambiar el tipo de inicio a "Deshabilitado". Pulsar
en "Aceptar" y cerrar la ventana de servicios.


Una vez desactivado el servicio de mensajería podemos verificar que
nuestro ordenador ya no puede recibir este tipo de mensajes utilizando el
servicio de verificación existente en

http://www.mynetwatchman.com/winpopuptester.asp


Xavier Caballé
xavi@hispasec.com



jueves, 27 de febrero de 2003

Una vulnerabilidad de Windows Me permite la ejecución de programas

Se ha descubierto un problema en Windows Me que puede permitir la
visualización o ejecución de cualquier archivo o programa del disco duro
simplemente al pulsar un enlace de una página web, e incluso dependiendo
de las configuraciones, sin interacción de usuario, con sólo recibir un
e-mail maliciosamente construido.

"Help and Support Center" (HSC) proporciona recursos centralizados a
través de los cuales los usuarios pueden obtener ayuda en una variedad
de asuntos. Por ejemplo, proporciona la documentación del producto,
ayuda para determinar compatibilidad del hardware, acceso a la
actualización de Windows, ayuda en línea de Microsoft, y otras ayudas.
Los usuarios y los programas pueden ejecutar enlaces URL para Help and
Support Center mediante el uso de "hcp://" en una URL en vez de
"http://".

Se ha detectado una vulnerabilidad en Help and Support Center incluido
en Windows Me debido a un desbordamiento de búfer en el tratamiento del
prefijo "hcp://". Un atacante puede explotar la vulnerabilidad si
construye una URL que, cuando sea pulsada por el usuario, ejecute el
código deseado por el atacante. La URL puede estar hospedada en una
página web o bien ser enviada directamente por e-mail.

En un ataque a través de una página web, donde el usuario pulsa en una
URL hospedada en un sitio web, un atacante tendrá la posibilidad de leer
o ejecutar archivos presentes en el sistema atacado. En el caso de un
ataque a través de un e-mail, si el usuario tiene instalado Outlook
Express 6.0 u Outlook 2002 con su configuración por defecto, o bien
Outlook 98 o 2000 con Outlook Email Security Update, el ataque no será
automático al necesitar la interacción del usuario para pulsar en el
enlace malicioso incluido en el e-mail. Sin embargo, si el usuario no
tiene la configuración por defecto en Outlook Express 6.0 u Outlook
2002, o no hace uno de Outlook Email Security Update junto con Outlook
98 o 2000, el ataque podrá lanzarse de forma automática sin necesidad de
que el usuario pulse en la URL del e-mail.

Microsoft ha publicado la actualización necesario para corregir el
problema que puede descargarse desde:
http://windowsupdate.microsoft.com


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin MS03-006
Flaw in Windows Me Help and Support Center Could Enable Code Execution
(812709)
http://www.microsoft.com/technet/security/bulletin/ms03-006.asp

What You Should Know About Microsoft Security Bulletin MS03-006
Security Update for Microsoft Windows Millennium Edition (Windows Me)
http://www.microsoft.com/security/security_bulletins/ms03-006.asp

miércoles, 26 de febrero de 2003

La seguridad de las tarjetas de crédito en entredicho

Se ha presentado un estudio que demuestra la vulnerabilidad de los
sistemas de seguridad utilizados por los cajeros automáticos para la
validación de los PIN asociados a las tarjetas de crédito. Este estudio
se ha visto empañado por los intentos que está realizando Citibank para
ocultar esta información.

En un estudio titulado "Decimalisation table attacks for PIN cracking",
dos investigadores de la universidad de Cambridge (Reino Unido)
presentan un estudio de las debilidades existentes en los dispositivos
hardware para el almacenamiento seguro y la validación de los PIN
asociados a las tarjetas de crédito comúnmente utilizado por las
instituciones financieras.

Las tarjetas de crédito son un clásico ejemplo de un sistema de
autenticación de doble factor, ya que se combina un elemento físico que
es necesario poseer (la tarjeta de plástico con su banda magnética) con
un elemento que teóricamente sólo conoce el titular de la tarjeta de
crédito (el PIN, un código numérico habitualmente de cuatro caracteres)
que físicamente no reside en ningún sitio. Para poder utilizar la
tarjeta de crédito en un cajero automático es necesario disponer de
estos dos elementos al mismo tiempo.

Obtener el plástico tarjeta de crédito es una tarea relativamente
simple. Son un elemento de libre distribución y comercialización.
Falsificar la banda magnética también es una operación no demasiado
complicada, como hemos leído infinidad de veces en las noticias sobre
estafas que, periódicamente, publican los medios de comunicación.

Lo que, en teoría, ya no es tan fácil obtener o identificar es el PIN
que el usuario ha seleccionado para la tarjeta de crédito. En teoría, la
única forma de identificar este PIN es o bien obligando al titular de la
tarjeta a que lo revele o utilizando técnicas de fuerza bruta para su
identificación.

En el caso de la fuerza bruta, la teoría conocida hasta la fecha es que
para identificar el PIN asociado a la tarjeta son necesarios, de
promedio, unos 5.000 intentos.

El estudio publicado este mes muestra que en realidad, una persona con
los conocimientos adecuados de los mecanismos de seguridad utilizados y
acceso a los sistemas criptográficos que se utilizan en los bancos,
únicamente necesita un máximo de 15 intentos para identificar cualquier
código PIN de cualquier tarjeta de crédito.

La vulnerabilidad utilizada se encuentra en los dispositivos hardware
utilizados para la realización de las operaciones criptográficas. Se
trata de unos procesadores especialmente diseñados para esta acción,
capaces de realizar un gran número de operaciones por segundo.

Una vez más, la teoría indica que estos equipos están especialmente
protegidos para la realización de cualquier ataque. No sólo disponen de
protecciones especiales para evitar su manipulación, sino que las
funciones que ofrecen a los programas están diseñadas para devolver un
valor booleano (verdadero o falso) a cualquier petición, para evitar la
divulgación de información que sirva para confeccionar ataques basados
en el estudio estadístico de los errores reportados.

Estos sistemas criptográficos realizan la validación del PIN realizando
un cifrado de los dígitos introducidos, utilizando una clave secreta.
Del resultado de la operación de cifrado se extraen una serie de
dígitos, expresados en base hexadecimal. Como el PIN de la tarjeta
utiliza únicamente números de base decimal, se hace necesaria la
conversión.

La conversión de hexadecimal a decimal no se realiza de forma
matemática, sino que se aplica una tabla de conversión, donde se expresa
la conversión a realizar para cada dígito hexadecimal. Por ejemplo, una
tabla de conversión puede ser

0123456789ABCDEF
9876543210987654

Utilizando esta tabla, el valor hexadecimal 67F4 se convertiría en el
valor decimal 3245. Este seria, en definitiva el PIN que debería
cotejarse para determinar si la operación debe realizarse o no.

Es en este punto donde se encuentra la vulnerabilidad del protocolo.
Estas tablas de conversión no son un valor sensible, sino que es posible
facilitar una tabla de conversión arbitraria, conjuntamente con el
número de cuenta y el PIN, en el momento de solicitar al sistema
criptográfico la validación de la información.

Por tanto, un empleado del banco con acceso al sistema dispone de la
capacidad de manipular las tablas de conversión para determinar los
dígitos que forman el PIN. Por ejemplo, utilizando esta tabla de
conversión

0123456789ABCDEF
0000000100000000

con el código PIN 0000 es posible identificar si el PIN contiene el
número 7.

Por tanto, básicamente lo que demuestra el estudio, una vez más, es que
utilizar como medida de seguridad el desconocimiento ("security by
obscurity") no es efectivo, especialmente cuando se hace referencia a
cuestiones relacionadas con la criptografía.


El lado oscuro de esta historia

Un problema de este tipo, que requiere una situación muy específica para
poder ser utilizado, probablemente hubiera pasado más o menos
desapercibido fuera de los círculos de interés sobre criptografía y
seguridad informática. De hecho, como se deduce de lo publicado
anteriormente, las únicas personas que podrían aprovecharse de esta
vulnerabilidad para obtener los PIN de las tarjetas de crédito son
algunos empleados de los bancos que disponen del acceso necesario a los
sistemas criptográficos.

Ahora bien, se ha producido un elemento, muy grave, que ha dado un matiz
totalmente diferente a esta historia. Y es que Citibank, una de las
mayores corporaciones bancarias del mundo, ha utilizado las armas
legales a su alcance para intentar ocultar este estudio y censurar la
publicación de esta información.

Tal como recogemos en el apartado de "Más información", Citibank ha
solicitado al Tribunal Supremo del Reino Unido la retirada del estudio
al que hemos hecho referencia.

En el momento de redactar este boletín, una de las páginas web donde
estaba disponible esta investigación (también publicada por la revista
que edita Microsoft Research) no permite el acceso a la información, con
un código de error HTPP 403 (acceso prohibido). No podemos afirmar que
sea debido a la actuación de Citibank, pero así lo parece indicar.


Xavier Caballé
xavi@hispasec.com



martes, 25 de febrero de 2003

Gusano/troyano "Lovgate" responde a los e-mails

La variante "C" de este gusano ha conseguido en las pasadas horas
índices elevados de propagación, hasta situarse en el top 5 en la
lista de virus más distribuidos de las últimas 24 horas en el ámbito
internacional. Lo más destacado, y tal vez lo que más resultado le
está dando en su fase de propagación, es el uso de la Ingeniería
Social. Entre otras técnicas, el gusano se distribuye por e-mail
simulando ser respuestas a los mensajes nuevos que se encuentran en
la bandeja de entrada de los usuarios infectados.

De momento en España la incidencia es bastante más baja en comparación
con otros países. Parte de culpa es de suponer que la tenga el
lenguaje que utiliza "Lovgate", a los usuarios les parecerá sospechoso
escribir un mensaje a un conocido en español y recibir la supuesta
respuesta en inglés. Aunque como ha ocurrido a lo largo de la historia
con otros especímenes, es de esperar que también tenga cierta
actividad en el resto de países de manera independiente a su lengua.

En su faceta como troyano, sitúa el puerto TCP/10168 a la escucha,
notifica la existencia del sistema infectado al autor del virus por
e-mail (hacker117@163.com), permitiéndole autentificarse y tener
control sobre el sistema de forma remota.

Como gusano recoge las direcciones de remitente, asunto y cuerpos de
los mensajes nuevos de la bandeja de entrada de Outlook y Outlook
Express, para simular ser una respuesta que envía utilizando un
servidor SMTP fijo (smtp.163.com). En la composición del mensaje
incluye los siguientes textos fijos, lo que nos facilitará su
detección a primera vista:

Asunto: Re: [asunto original del mensaje que enviamos y ha respondido]

Cuerpo:

[nombre de usuario que escribió el mensaje original] wrote:
====
> [texto original del mensaje que se envió]
====
[dominio de correo del envío original] account auto-reply:


I'll try to reply as soon as possible.
Take a look to the Adjunto and send me your opinion!


El archivo adjunto, que contiene el gusano/troyano, puede tener alguno
de los siguientes nombres:

fun.exe
humor.exe
PsPGame.exe
docs.exe
tamagotxi.exe
s3msong.exe
midsong.exe
billgt.exe
Card.EXE
SETUP.EXE
searchURL.exe
news_doc.exe
joke.exe
images.exe
hamster.exe
pics.exe

Además de la propagación simulando respuestas a los mensajes nuevos de
la bandeja de entrada, el gusano busca archivos con extensión .HT*
(HTM y HTML) para recoger direcciones de correo a las que se autoenvía
por e-mail con algunos de los siguientes formatos:

Asunto: Documents
Adjunto: Docs.exe
Cuerpo: Send me your comments...

Asunto: Roms
Adjunto: Roms.exe
Cuerpo: Test this ROM! IT ROCKS!.

Asunto: Pr0n!
Adjunto: Sex.exe
Cuerpo: Adult content!!! Use with parental advisory.

Asunto: Evaluation copy
Adjunto: Setup.exe
Cuerpo: Test it 30 days for free.

Asunto: Help
Adjunto: Source.exe
Cuerpo: I'm going crazy... please try to find the bug!

Asunto: Beta
Adjunto: _SetupB.exe
Cuerpo: Send reply if you want to be official beta tester.

Asunto: Do not release
Adjunto: Pack.exe
Cuerpo: This is the pack ;)

Asunto: Last Update
Adjunto: LUPdate.exe
Cuerpo: This is the last cumulative update.

Asunto: The patch
Adjunto: Patch.exe
Cuerpo: I think all will work fine.

Asunto: Cracks!
Adjunto: CrkList.exe
Cuerpo: Check our list and mail your requests!


Si ejecutamos el archivo adjunto, el gusano comenzará la infección del
sistema. En primer lugar se copiará en la carpeta de sistema de
Windows con los nombres:

WinRpcsrv.exe
syshelp.exe
winrpc.exe
WinGate.exe
rpcsrv.exe

Dependiendo de nuestra versión de Windows, y según opciones de
instalación por defecto, la carpeta de sistema podría ser
C:\Windows\System en el caso de Windows 9x/Me, C:\Winnt\System32 para
Windows NT/2000 o C:\Windows\System32 en Windows XP.


Si el sistema que está infectando es un Windows 9x/ME añade la entrada
run=rpcsrv.exe en el apartado [windows] del archivo Win.ini, para
forzar la ejecución del gusano cada vez que se inicie Windows.


A continuación, ya de forma independiente a la versión de Windows,
copia el componente troyano en la carpeta de sistema con los
siguientes nombres:

ily.dll
task.dll
reg.dll
1.dll


Modifica el registro de Windows para introducir los siguientes valores
en HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

syshelp %system%\syshelp.exe
WinGate initialize %system%\WinGate.exe -remoteshell
Module Call initialize RUNDLL32.EXE reg.dll ondll_reg

De esta forma cada vez que se inicie Windows ejecutará tanto al gusano
como su componente troyano.


Modifica además esta otra entrada de registro de Windows, que
provocará la ejecución del gusano cada vez que abramos un archivo de
texto:

HKEY_CLASSES_ROOT\txtfile\shell\open\command
(Default) = "winrpc.exe %1"

Recorre todas las unidades de red compartidas y se copia en las
carpetas a las que tiene acceso.

Si el sistema es un Windows NT/2000/XP, el gusano se instalará como
servicio con el nombre de "Windows Remote Service", que ejecutará el
archivo infectado winrpcsrvexe, mientras que el componente troyano
aparecerá con los nombres de "dll_reg" y "Windows Management
Extension" y corresponderán al archivo task.dll.

Se copia en la carpeta de sistema como ssrv.exe y creará la siguiente
entrada en el registro de Windows:

HKEY_LOCAL_MACHINE\Software\KittyXP.sql\Install

Modifica la siguiente entrada con el valor
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows
run rpcsrv.exe


Además intenta conectarse con todos los ordenadores de la red local
utilizando los usuarios "guest" y "Administrator", junto con alguna
de las siguientes contraseñas:

[cadena vacia] (sin contraseña)
123
321
123456
654321
guest
administrator
admin
111111
666666
888888
abc
abcdef
abcdefg
12345678
abc123

Si logra conectarse con algún sistema, copia el gusano en
\\\admin$\system32\stg.exe y lo ejecuta como
servicio bajo el nombre de "Microsoft NetWork Services FireWall."


Bernardo Quintero
bernardo@hispasec.com


Más información:

W32.HLLW.Lovgate.C@mm
http://www.sarc.com/avcenter/venc/data/w32.hllw.lovgate.c@mm.html

W32/Lovgate@M
http://vil.nai.com/vil/content/v_100072.htm

Lovgate.C
http://www.pandasoftware.es/virus_info/enciclopedia/detalles.aspx?idvirus=38875

WORM_LOVGATE.C
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_LOVGATE.C

I-Worm.Supnot (aka Lovgate)
http://www.viruslist.com/eng/viruslist.html?id=59628

lunes, 24 de febrero de 2003

Informe anual del CERT

El CERT (Computer Emergency Response Team) acaba de publicar un informe
en que analiza las actividades realizadas en el pasado año. En este
informe se ofrece un resumen de los avisos publicados en el 2002.

Desde enero hasta diciembre de 2002, el CERT/CC recibió 204,841 mensajes
de correo y más de 880 llamadas informando de incidentes de seguridad
informática o solicitando información. Se recibieron 4.129 avisos de
vulnerabilidades y trató 82.094 incidentes de seguridad durante dicho
periodo.

Durante el 2002 el CERT publicó 37 avisos de seguridad, 6 notas de
incidentes y 375 notas de incidentes. Entre las incidencias de
intrusiones tratadas y de las que el CERT/CC publicó información el
informe destaca la explotación de vulnerabilidades en Microsoft SQL
Server y el gusano Apache/mod_ssl. Por otra parte, entre las
vulnerabilidades más significativas el CERT destaca las que afectaron a
BIND y al protocolo SNMP.


Antonio Ropero
antonior@hispasec.com


Más información:

CERT® Coordination Center 2002 Annual Report
http://www.cert.org/annual_rpts/cert_rpt_02.html

domingo, 23 de febrero de 2003

Problemas de seguridad en SYBASE

Las versiones no actualizadas de la base de datos SYBASE contienen
numerosas vulnerabilidades de seguridad que, entre otras cosas, permiten
la ejecución de código arbitrario en el servidor.

Algunas de las vulnerabilidades son:

* Desbordamiento de búfer al invocar la función "xp_freedll" al
proporcionarle un parámetro de longitud excesiva. El desbordamiento
permite la ejecución de código arbitrario.

Esta vulnerabilidad afecta a la versión MS Windows de SYBASE.

* Desbordamiento de búfer en la función "DBCC CHECKVERIFY", permitiendo
la ejecución de código arbitrario en el servidor.

Esta vulnerabilidad afecta a todas las plataformas soportadas
por SYBASE.

* Desbordamiento de búfer en la ejecución de "DROP DATABASE",
permitiendo la ejecución de código arbitrario en el servidor.

Esta vulnerabilidad afecta a todas las plataformas soportadas
por SYBASE.

El fabricante ha publicado parches para estas vulnerabilidades. Los
administradores de sistemas SYBASE pueden descargarlos desde su web.


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


Más información:

Sybase Adaptive Server xp_freedll Buffer Overrun Vulnerability
http://www.securityfocus.com/bid/6266

SHATTER Team Security Alert
Sybase: xp_freedll Buffer Overflow
http://www.appsecinc.com/resources/alerts/sybase/02-0003.html

Sybase Adaptive Server buffer overflow in xp_freedll extended stored
procedure
http://archives.neohapsis.com/archives/bugtraq/2002-11/0345.html

Sybase Adaptive Server DBCC CHECKVERIFY Buffer Overflow Vulnerability
http://www.securityfocus.com/bid/6269

Sybase Adaptive Server buffer overflow in DBCC CHECKVERIFY
http://archives.neohapsis.com/archives/bugtraq/2002-11/0337.html

SHATTER Team Security Alert
Sybase: DBCC CHECKVERIFY Buffer Overflow
http://www.appsecinc.com/resources/alerts/sybase/02-0001.html

Sybase Adaptive Server DROP DATABASE Buffer Overflow Vulnerability
http://www.securityfocus.com/bid/6267

Sybase Adaptive Server buffer overflow in DROP DATABASE
http://archives.neohapsis.com/archives/bugtraq/2002-11/0339.html

SHATTER Team Security Alert
Sybase: DROP DATABASE Buffer Overflow
http://www.appsecinc.com/resources/alerts/sybase/02-0002.html

Multiple Vulnerabilities in Sybase Adaptive Server 12.0 and 12.5
http://www.secadministrator.com/Articles/Index.cfm?ArticleID=27459

Parches "Sybase Adaptive Server Enterprise"
http://downloads.sybase.com/swd/swx

sábado, 22 de febrero de 2003

Interceptación de contraseñas en canales SSL/TLS

Un grupo de investigadores suizo demuestra la existencia de una
vulnerabilidad de revelado de información en SSL/TLS, que puede permitir a
un atacante identificar la clave utilizada para el cifrado de una sesión.

SSL (Secure Sockets Layer, capa de conexión segura) y TLS (Transport Layer
Security, capa de seguridad del transporte) son dos métodos utilizados
para ofrecer cifrado y integridad de datos en las comunicaciones entre dos
entes a través de una red informática.

SSL fue inicialmente desarrollado e implementado por Netscape en 1994 para
ofrecer a los usuarios la garantía que la información sensible transmitida
a través de Internet permanecía totalmente privada e íntegra, incluso
cuando un atacante disponía de la opción de capturar la sesión (tráfico
entre el cliente y el servidor). El protocolo TLS es una propuesta de
estándar, recogida en el RFC 2246, que nace como una evolución de SSL 3.0.

Aunque tradicionalmente el uso más frecuente de SSL/TLS es para el cifrado
de las páginas web, en realidad estos protocolos de transporte son
totalmente independientes del protocolo de aplicación. Es decir, se puede
utilizar SSL/TLS para el cifrado de protocolos de aplicación como Telnet,
FTP, SMTP, IMAP o el propio HTTP.

SSL/TLS no ofrecen únicamente la capacidad de cifrar la información, sino
que también permiten a cada una de las partes identificarse de forma
fehaciente, lo que evita posibles ataques de suplantación o de
interceptación de sesiones ("man-in-the-middle").

Para el cifrado del tráfico, SSL/TLS utilizan algoritmos de clave
simétrica (como DES, AES...) o bien clave variable (RC4, por ejemplo)
mientras que para la autenticación de los participantes se utilizan
certificados digitales (tecnología de clave pública y privada).

La vulnerabilidad descubierta permite a un atacante, que disponga de la
capacidad de monitorizar y manipular múltiples sesiones SSL/TLS donde se
utilice una clave fija para el cifrado de la sesión, como puede ser una
contraseña, utilizar un vector de ataque específico que le permita la
identificación de esa clave de cifrado.

De una forma muy resumida, la operación de cifrado de SSL/TLS conlleva
calcular un código de autenticación que se añade al texto a cifrar. Este
texto más código es dividido en bloques del tamaño de entrada del
algoritmo de cifrado (normalmente, 8 bytes), rellenando los posibles bits
libres. Una vez obtenidos estos bloques, se les aplica el algoritmo de
cifrado.

El receptor de los bloques cifrados debe proceder a separar las diversas
partes (texto, código de autenticación, bits de relleno y longitud del
bloque) y realizar la verificación del relleno. Si la verificación es
exitosa, se procede a verificar el código de autenticación.

Esto puede ser aprovechado por un atacante, que disponga de la capacidad
de interceptar y manipular el tráfico de las sesiones, para determinar
cual es la contraseña utilizada para el cifrado. Midiendo el tiempo de
respuesta se puede identificar cual es el error identificado: en la
verificación del relleno o en la verificación del código de autenticación.

El ataque consiste básicamente en estos pasos:

1. El atacante intercepta el bloque que desea descifrar (la contraseña)
que envía uno de los participantes de la sesión.
2. El atacante envía al otro participante un bloque construido por él a
partir del bloque interceptado.
3. El servidor remitirá un mensaje de error al atacante. Este mensaje
indicará que tipo de error se ha producido, si durante la verificación de
los bits de relleno o durante la verificación del código de autenticación.

Este tipo de ataque requiere que el mensaje utilizado para el cifrado sea
el mismo durante un gran número de sesiones. En el ejemplo práctico
utilizado por los investigadores suizos, se ha utilizado un cliente de
correo, que periódicamente consulta al servidor de correo la posible
existencia de nuevos mensajes.

OpenSSL, un desarrollo de código abierto que implementa los protocolos
SSL/TLS, ha publicado una nueva versión que impide la realización de este
tipo de ataque, ya que siempre se realiza la verificación del código de
autenticación incluso cuando la primera verificación es errónea. De esta
forma, el atacante no recibe la suficiente información para discernir el
tipo de error detectado.


Xavier Caballé
xavi@hispasec.com



viernes, 21 de febrero de 2003

Bases de datos de "hashes"

Desde hace unas semanas, está disponible una amplia base de datos de
"hashes" de ficheros, distribuciones e imágenes "ISO", para poder
comprobar su integridad y autenticidad.

Un "hash" es una función criptográfica que produce una salida de
longitud fija (típicamente 128 o 160 bits) a partir de una entrada
arbitrariamente larga. Un buen "hash" debe cumplir las siguientes
propiedades:

a) El resultado final no debe dejar traslucir ninguna información sobre
los datos originales. A todos los efectos, debe parecer aleatorio.

b) Dado un resultado determinado, no hay otro sistema aparte de
la fuerza bruta para generar datos de entrada capaces de producir
dicho resultado.

c) Dados unos datos de entrada y su "hash", no debe haber un atajo
(aparte de la fuerza bruta) para generar otros datos de entrada
distintos, con el mismo "hash".

Existen muchos algoritmos de "hash", pero los más populares son MD5 y
SHA-1.

Si obtenemos un "hash" de un archivo y lo comparamos con una base de
datos de "hashes" correctos y confiables, sabremos si nuestro fichero ha
sido modificado o está corrompido. Por las propiedades indicadas, las
probabilidades de que un atacante pueda modificar un archivo de forma
que su "hash" siga coincidiendo son muy bajas. Por el teorema del
cumpleaños sabemos, por ejemplo, que si el hash tiene 160 bits, se
requieren del orden de 2^80 pruebas (más o menos un cuatrillon, un uno
seguido de 24 ceros). Suponiendo que el atacante genere mil millones de
pruebas por segundo, tardaría unos 3.8 millones de años en hallar una
prueba válida.

Recordamos a nuestros lectores que ante la duda, la verificación de los
archivos debe realizarse reiniciando la máquina desde un kernel
"confiable" (idealmente residente en un floppy protegido contra
escritura o en un CDROM) y que el programa de cálculo de "hashes"
también debe encontrarse en un medio confiable. De esa forma se evita el
riesgo de que un atacante haya contaminado las propias herramientas de
verificación con troyanos.

Hace casi tres años ya informamos de una base de datos similar, en SUN,
para entornos Solaris, pero en esta ocasión la base de datos disponible
permite acceder a "hashes" de sistemas Solaris, FreeBSD, Linux y
MacOS-X. El gobierno norteamericano tiene una base de datos similar
que cubre también entornos como Microsoft Windows.


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


Más información:

Known-Good MD5 Database
http://slashdot.org/article.pl?sid=02/12/09/0411224

KnownGoods Database
http://www.knowngoods.org/

http://www.hispasec.com/unaaldia/560
09/05/2000 - Solaris Fingerprint Database

SECURITY INFORMATION - Solaris Fingerprint Database
http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl

RDS Product Search
http://patapsco.nist.gov/itl/div897/nsrl/ps.asp

jueves, 20 de febrero de 2003

Publicación del informe de incidentes de seguridad 2002 de IRIS-CERT

El pasado enero, RedIRIS publicó un pequeño informe de seguridad de
IRIS-CERT, referente al año 2002.

El IRIS-CERT es el centro de respuesta ante incidentes de seguridad
informática de RedIRIS. RedIRIS es la red informática académica y de
investigación española.

Algunas estadísticas:

* Durante 2002 se atendieron 1495 incidentes de seguridad informática,
suponiendo un incremento del 44% respecto a 2001.

* Más de la mitad de los incidentes comunicados por organizaciones
asociadas implicaban máquinas comprometidas dentro de RedIRIS.

El documento es muy corto y se lee en pocos minutos, siendo interesante
para conocer el estado de la comunidad académica española y contrastarlo
con el del resto del planeta.


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


Más información:

Informe de incidentes de seguridad año 2002
http://www.rediris.es/cert/doc/informes/2002/

miércoles, 19 de febrero de 2003

Actualización de PHP

Existe una vulnerabilidad en PHP, cuando se ejecuta en modalidad de CGI,
que puede ser utilizada por un atacante para acceder al contenido de
archivos del servidor web o para forzar la ejecución de código PHP
arbitrario.

PHP (PHP: Hypertext Preprocessor) es un popular lenguaje de scripting de
propósito general, idóneo para el desarrollo en web al ser posible su
integración dentro del HTML. Se trata de un desarrollo de código abierto
muy utilizado para la confección de páginas web dinámicas (gracias a la
capacidad de lanzar consultas a bases de datos).

El código PHP, a diferencia de otros lenguajes de scripting, reside dentro
de una página HTML. En una configuración estándar, cuando el servidor
recibe la petición de una página que contiene código PHP, antes de
enviarla, utiliza el intérprete de PHP para realizar las acciones
programadas.

Habitualmente la integración del intérprete PHP con el servidor web se
realiza a través de un modulo o extensión del propio servidor web. No
obstante, cuando no existe este módulo es necesario ejecutar el intérprete
directamente como un CGI.

Para evitar posibles problemas de seguridad, ya que es extremadamente
peligroso dejar un intérprete de un lenguaje accesible en un servidor web,
en la configuración de PHP se puede impedir la utilización directa del
intérprete. Para ello se utiliza la opción cgi.force_redirect=1 en el
archivo php.ini o bien, durante la compilación, la opción --enable-force-
cgi-redirect.

No obstante, como consecuencia de una vulnerabilidad de seguridad en la
versión 4.3.0, un atacante puede ingeniárselas para saltarse esta
protección lo que permitirá la posibilidad de ejecutar código PHP
arbitrario.

Esta vulnerabilidad puede permitir a un atacante con acceso al servidor
web utilizar la vulnerabilidad para acceder a cualquier archivo para el
cual el usuario que ejecuta el servidor web dispone de permiso de lectura.
La vulnerabilidad también puede ser aprovechada por un atacante remoto
para forzar la ejecución de código PHP arbitrario.

El grupo PHP ha publicado la versión 4.3.1 que corrige estos problemas de
seguridad. Esta nueva versión deberá instalarse lo antes posible en todos
aquellos servidores que utilicen el módulo CGI para ejecutar el código
PHP.


Xavier Caballé
xavi@caballe.com



martes, 18 de febrero de 2003

Comprometidos los datos de más de cinco millones de tarjetas de crédito

Un atacante ha conseguido la información de más de cinco millones de
tarjetas de crédito de usuarios estadounidenses.

Según han reconocido los portavoces de VISA y MasterCard, los datos
comprometidos alcanzan los 2,2 millones de tarjetas MasterCard y
aproximadamente 3,4 millones de tarjetas VISA. Si bien algunas fuentes
elevan la cifra hasta los 8 millones, al incluir las tarjetas American
Express, también afectada. Si bien esta compañía no ha especificado el
número de usuarios perjudicados. Si bien, todas las entidades aclaran
que los datos no han sido empleados de forma fraudulenta.

El atacante obtuvo los datos de los números de tarjetas de crédito tras
comprometer la seguridad de una tercera compañía encargada de procesar
las transacciones de las tarjetas de crédito en nombre de comerciantes.

Las entidades afectadas tampoco han llegado a identificar a la tercera
compañía atacada ni el tipo de intrusión ocurrido. Por lo que hasta el
momento no se puede llegar a determinar con exactitud si el compromiso
de los datos ha sido provocado por un atacante externo, por un acceso
no autorizado de un empleado o por cualquier otro tipo de robo físico
de los datos.


Antonio Ropero
antonior@hispasec.com



lunes, 17 de febrero de 2003

Problemas de seguridad en Lotus Domino

Se han dado a conocer diversos problemas de seguridad en varios
componentes de la familia de productos Lotus Domino, clasificadas como
críticas al permitir a un atacante obtener el control del servidor donde
se ejecuta Lotus Domino o forzar la ejecución de código en las máquinas
de los usuarios de iNotes.

Lotus Domino es una familia de servidores de IBM para el trabajo en
grupo y el e-business, que abarcan desde sistemas de mensajería
electrónica a transacciones electrónicas vía Web y cualquier cosa que
pueda existir entre estos dos extremos. Recientemente se ha informado de
la existencia de diversos problemas de seguridad en algunos componentes
de esta familia de productos.

* Desbordamiento de búfer en Lotus iNotes 6.0

Cuando se instala iNotes, automáticamente se añade un control ActiveX
denominado Lotus Domino Session ActiveX. Existe una vulnerabilidad de
desbordamiento de búfer en la función InitializeUsingNotesUserName que
puede ser utilizado para ejecutar código arbitrario en la máquina del
usuario, con los privilegios de seguridad del usuario que esté conectado
en la máquina.

Esta vulnerabilidad puede ser aprovechada por un atacante malévolo a
través de una página web o un mensaje de correo electrónico.

* Desbordamiento de búfer en iNotes Web Server 6.0

Uno de los componentes de Lotus Domino es un servidor web que permite el
acceso de los usuarios del sistema a sus carpetas de correo electrónico.
Se ha descubierto la existencia de una vulnerabilidad de desbordamiento
de búfer cuando se envía una petición que contenga un valor muy largo en
el parámetro PresetFields (opción s_ViewName).

Esta vulnerabilidad puede ser aprovechada para ejecutar código
arbitrario en el servidor Lotus Domino, con los privilegios de la cuenta
de usuario que ejecute el servicio web de Domino.

* Desbordamiento de búfer en Lotus Domino 6.0

La tercera vulnerabilidad anunciada hoy se encuentra en el servidor web
de Lotus Domino. Cuando el servidor web debe enviar al usuario remoto
una respuesta de tipo 302 (el objeto se encuentra en una URL diferente),
construye el paquete HTTP utilizando, entre otros campos, el nombre de
máquina enviado por el cliente que ha realizado la solicitud.

Si el nombre de máquina enviado se puede provocar un desbordamiento de
búfer en el servidor web. Esta vulnerabilidad puede ser aprovechada por
un atacante para conseguir el control del proceso que ejecuta el
servicio web de Domino, lo que a su vez puede permitir obtener el
control de todo el servidor.

Todas estas vulnerabilidades se encuentran corregidas en la versión
6.0.1 de Lotus Notes y Domino, disponible en la web de soporte de Lotus.


Xavier Caballé
xavi@hispasec.com



domingo, 16 de febrero de 2003

Vulnerabilidad en HP-UX 10.20, 11.00 y 11.11

Los servidores HP9000 con el sistema operativo HP-UX en sus versiones
10.x y 11.x se ven afectados por un problema de seguridad por el que un
atacante podría elevar sus permisos en el sistema.

Esta vulnerabilidad está causada por un problema en el comando
"enable/disable" el cual no pone limite en la introducción de datos.
Esto puede ocasionar un desbordamiento de buffer si un atacante
introduce un argumento excesivamente largo con el comando "disable".
Este problema permitirá al atacante la ejecución de código en el sistema
afectado.

HP informa que esta vulnerabilidad queda solucionada con los parches
HPSBUX0208-213 que pusieron a disposición de sus usuarios con fecha 26
de agosto de 2002 para solucionar otro problema. Si no se instalaron
anteriormente los parches se pueden bajar de la dirección: itrc.hp.com

HP-UX 10.20 - PHCO_27133
HP-UX 11.00 - PHCO_27132
HP-UX 11.11 - PHCO_27020


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


Más información:

HP-UX Privilege Escalation via 'disable'
http://www.secunia.com/advisories/8063/

sábado, 15 de febrero de 2003

Spam Conference

A mediados del pasado mes de enero se celebró en el MIT la primera
conferencia dedicada al SPAM, centrada en analizar el estado del arte de
la tecnología para detección y eliminación del SPAM.

La conferencia fue organizada por el MIT y se presentaron diversas
ponencias sobre la actualidad en la lucha contra el spam. A continuación
presentamos un resumen de las mismas, facilitando la URL donde está
disponible la presentación.

Para todos aquellos que no tuvimos la oportunidad de asistir en vivo, es
posible ver la totalidad de la conferencia vía Internet, ya que todas
las ponencias fueron registradas en vídeo y están disponibles en formato
Real en la dirección:

http://www.spamconference.org/webcast.html

* Gnus versus Spam
Teodor Zlatanov
> http://lifelogs.com/spam/spam.pdf

Gnus es un lector de correo y newsgroups basado en GNU Emacs. Esta
ponencia se centra en el paquete spam.el, que añade a Gnus la
posibilidad de realizar un filtrado de los mensajes para eliminar
aquellos que son identificados como spam.

* Filtrado de mensajes a partir del análisis del hash polinominal y la
discriminación CRM114
Bill Yerazunis
> http://crm114.sourceforge.net/crm_slides/CRM114_slides.html

La técnica de filtros bayesianos, basada en la estadística, se ha
mostrado muy eficiente para la identificación del spam. En esta ponencia
se presenta una generalización del método bayesiano, basado en el
análisis del hash polinominal que permite la identificación de palabras
y frases modificadas. La aplicación de este sistema permite obtener una
fiabilidad superior al 99,5%, realizando el filtrado en tiempo real.

* Filtrado adaptable del spam
Jason Rennie
> http://www.ai.mit.edu/~jrennie/talks/spam03.pdf

Todas las técnicas existentes en la actualidad para la identificación
del spam adolecen de un problema: no se adaptan a los cambios que
realizan los spammers. Este es un problema común a los sistemas basados
en filtros bayesianos o en listas negras. El autor de esta ponencia
presenta un nuevo método de identificación del spam, basado en el
aprendizaje dinámico de patrones.

* El compendio de los spammers
John Graham-Cumming
> http://popfile.sourceforge.net/SpamConference011703.pdf

Se presente POPFILE, un proxy POP3 que se instala en la máquina del
usurario final y realiza una clasificación bayesiana de los mensajes
entrantes en un número arbitrario de clases. Se trata de un sistema cada
vez más popular para la lucha contra el spam.

La ponencia presenta algunas de las técnicas que utilizan los Spammers
para saltarse este tipo de filtros y cuales son las técnicas que utiliza
POP3FILE para evitar todos estos trucos.

* Siguiendo sus patrones
John Draper

El autor de la ponencia se dedica a analizar el comportamiento de los
spammers. Si bien el comportamiento de los mismos no es del todo
consistente, el análisis de muchos generadores masivos de spam ha
permitido identificar una serie de patrones que pueden ser de interés en
la lucha contra el spam.

* Infraestructura necesaria para la investigación del Spam
Paul Judge
> http://www.ciphertrust.com/resources/presentations/spamconf2003/spamresearch.pdf

La escala y tamaño del spam hace que hoy en día ya pueda clasificarse
como una autentica epidemia y no ya una simple molestia. Se ha
convertido, en definitiva, en un problema de seguridad de la
información.

Para analizar de una forma eficiente este problema, debe disponerse de
una infraestructura adecuada, como archivos estandarizados para la
investigaciones (como los disponibles en SpamArchive.org), herramientas
de investigación y conferencias técnicas.

* Mejor filtrado bayesiano del Spam
Paul Graham
> http://paulgraham.com/better.html

Hace solo un año, Paul Graham presentó un simple algoritmo basado en la
utilización de técnicas bayesianas de estadística que permitía
identificar el 99% del spam, con un porcentaje casi nulo de falsos
positivos. En esta ponencia se presentan algunas mejoras en el
algoritmo, que permiten conseguir un mayor rendimiento.

* eXpurgate, un método diferente para el filtrado del correo y la
detección del Spam
Robert Rothe

eXpurgate es un servicio dirigido a empresas y que les permite una
protección fiable contra el spam. ¿Cómo funciona este servicio? ¿Cuáles
son las técnicas de filtrado utilizadas?

* Filtrado de spam a nivel de red
Matt Sergeant
> http://axkit.org/docs/presentations/spam/SpamConf2003.pdf

El filtrado de mensajes para identificar el spam, cuando se realiza a
nivel de red debe plantearse de una forma diferente el filtrado se
realiza únicamente en una cuenta de correo individualizada.

La ponencia se centra en las consideraciones a realizar cuando el
filtrado se realiza a nivel de red, así como las diferentes tecnologías
existentes. Se discute, también, el nuevo componente bayesiano de
SpamAsssassin.

* Técnicas anti-spam en python.org
Barry Warsaw

Existen actualmente casi un centenar de listas de correo en los
servidores de correo de python y zope. La ponencia presenta las técnicas
utilizadas para evitar la difusión de spam a través de estas listas, que
consisten en reglas de Exim4, la integración con SpamAssassin y las
técnicas anti-spam de Mailman.

La ponencia analiza la efectividad de estas técnicas y también como
afectan a nivel de administración de las listas. Se discuten también los
planes para el futuro.

* SmartLook: clasificador automático de correo para Outlook
Jean-David Ruvini

Se presenta una herramienta para los usuarios de Outlook que permite la
clasificación automática de los mensajes en carpetas, realizando la
predicción de la ubicación donde el usuario desea conservar el mensaje.
Esta posibilidad de clasificación automática, basada en la predicción a
partir del contenido del mensaje, puede utilizarse para filtrar
automáticamente el spam.

* Spam: ¿un peligro o una amenaza? El punto de vista de un ISP
Barry Shein

Desde el punto de vista de un proveedor de acceso a Internet, el spam es
peor de lo que a primera vista puede parecer. Si para la mayoría de la
gente el spam no es otra cosa que una 'molestia', para el ISP se
convierte en un autentica amenaza a su posibilidad de supervivencia.

El ponente discute las razones para considerar el spam como una
autentica amenaza y propone una posible solución al problema (que ya
adelanto no va a gustar a nadie).

* Lecciones de Bogofilter
Eric S. Raymond

Bogofilter es un sistema de filtrado basado en la utilización de
técnicas estadísticas bayesianas, a partir del trabajo de Paul Graham.
En esta ponencia Eric Raymond comenta que ha aprendido en el poco más de
medio año de vida de Bogofilter.

* Filtrado de spam: del laboratorio al mundo real
Joshua Goodman
> http://www.research.microsoft.com/~joshuago/spamconferenceshort.ppt

Esta ponencia discute las técnicas de filtrado de spam que ha
desarrollado Microsoft y las consideraciones a tener en cuenta para
mover un desarrollo del entorno de laboratorio al mundo real, donde será
utilizado por millones de usuarios. ¿Cómo evaluar el funcionamiento de
un filtro de spam?, ¿cómo realizar la evaluación de diversas
alternativas?

* Integración de heurística y n-grams utilizando Bayes y LMMSE
Michael Salib
> http://web.mit.edu/msalib/www/writings/talks/spam-filtering-conference/html/index.html

Si bien los filtros bayesianos disponen en estos momentos de una gran
popularidad, éstos pueden ser mejorados. En la ponencia se describe la
integración de detectores heurísticos de spam, mejorados con la
utilización de n-gram (para permitir la independencia del idioma).

* Cuarenta años de aprendizaje informático para la clasificación del
texto David Lewis
> http://www.daviddlewis.com/publications/slides/lewis-2003-0117-spamconf-slides.pdf

La primera experiencia de aprendizaje informático para la clasificación
de texto data del año 1961 (curiosamente también utilizaba las técnicas
bayesianas hoy tan populares). En esta ponencia se resume todo lo
aprendido en estos cuarenta años, tanto desde el punto de vista
académico como operativo. Para al ponente son mucho más importante las
técnicas utilizadas para la preparación del texto a analizar que no el
algoritmo particular utilizado para el aprendizaje.

* ¿Se pueden utilizar los recursos legales para combatir el spam?
Jon Praed
> http://www.spamconference.org/praed.pdf

Si bien las herramientas tecnológicas son un buen sistema para combatir
el spam, también la aplicación de los recursos legales existentes es un
buen sistema para combatir la difusión masiva de mensajes basura. De
hecho, ya hay mucha jurisprudencia (en Estados Unidos) de ISP que han
utilizado los recursos legales para combatir la utilización de su
infraestructura para el envío de spam. La ponencia analiza la situación
actual y las diversas proposiciones de nuevas normativas que son de
interés en la lucha contra el spam.

* Hace falta, desesperadamente, un consorcio anti-spam
David Berlind

David Berlind es un columnista de CNET que, cada semana escribe un
boletín que es recibido por más de un millón de lectores. Esto convierte
su buzón (donde recibe más de 600 mensajes diarios) en un autentico foco
de recepción de spam. Pero David Berlind no utiliza ningún sistema de
filtrado, para evitar que mensajes legítimos enviados por sus lectores
puedan ser ignorados.

Para el ponente se hace necesario que los diversos actores de la
industria se unan para trabajar conjuntamente en la solución del
problema. Si ya lo han hecho en el pasado, cooperando en las
especificaciones de XML, SOAP, Wi-Fi y Bluetooth, ¿por qué no pueden
hacerlo en la lucha contra el spam?

* Lucha contra el spam en tiempo real
Ken Schneider
> http://www.brightmail.com/press/2003_MIT_Spam_Conference/

El spam es un problema extremadamente dinámico. Los spammers
constantemente utilizan nuevas y cambiantes técnicas y sus herramientas
cada día son más sofisticadas. Además el problema crece y crece: en
septiembre de 2001 sólo el 8% del correo era spam; un año después, el
spam ya representaba un 38% del volumen total del correo.

La identificación del spam en tiempo real tiene un gran impacto en los
usuarios del correo. Esta ponencia presenta las técnicas utilizadas por
Brightmail, una empresa especializada en este tipo de filtrado.


Xavier Caballé
xavi@hispasec.com



viernes, 14 de febrero de 2003

Parche para el parche de Internet Explorer

Una vez más Microsoft se ve obligada a publicar un parche que corrija
los problemas colaterales nuevos ocasionados tras la instalación de
una actualización de Seguridad. En este caso el producto afectado es
Internet Explorer.

El pasado 5 de febrero Microsoft publicó un nuevo parche acumulativo
para las versiones 5.01, 5.5 y 6.0 de Internet Explorer (Hispasec
informó de esta actualización en el una-al-día del 6 de febrero).
Esta actualización, además corregía dos vulnerabilidades consideradas
de gravedad ya que podían permitir a un atacante la ejecución de
código malicioso en la máquina del usuario.

Tras esta publicación se ha descubierto un problema, no de seguridad
sino de pérdida de funcionalidades, introducido por la aplicación del
parche. Este problema puede afectar principalmente a los usuarios
finales. Específicamente el problema puede impedir que algunos
usuarios se autentifiquen en determinados sitios web de Internet
web como sitios basados en subscripciones, o incluso en el propio
servicio de correo MSN de Microsoft.

Este nuevo problema ha sido resuelto mediante la publicación de un
nuevo parche (hot fix 813951) disponible en:
http://www.microsoft.com/windows/ie/downloads/critical/813951/default.asp

Microsoft aclara que este nuevo parche es para solucionar un problema
que no es de seguridad, y que el anterior parche estaba (y está)
publicado para eliminar las vulnerabilidades anunciadas.


Antonio Ropero
antonior@hispasec.com


Más información:

February 2003, Update for Internet Explorer 6 SP1 (813951)
http://www.microsoft.com/windows/ie/downloads/critical/813951/default.asp

una-al-dia (06/02/2003) Nuevo parche acumulativo para Internet Explorer
http://www.hispasec.com/unaaldia/1565

Actualizaciones de Microsoft, un arma de doble filo
http://www.hispasec.com/unaaldia/1527

Boletín de seguridad de Microsoft (MS03-004)
Cumulative Patch for Internet Exploter (810847)
http://www.microsoft.com/technet/security/bulletin/MS03-004.asp

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

jueves, 13 de febrero de 2003

Múltiples vulnerabilidades en bases de datos Oracle

Se ha anunciado la existencia de múltiples vulnerabilidades en Oracle Database 8i y 9i que pueden permitir a un atacante la ejecución de código en los servidores afectados.

El primero de los problemas reside en un desbordamiento de búfer en oracle.exe. Los usuarios que puedan enviar grandes cantidades de datos a ciertas llamadas de funciones en oracle.exe podrán provocar el desbordamiento de búfer, éste podría permitir la ejecución de código arbitrario con los privilegios del proceso oracle.exe.

Existen otros problemas de desbordamiento de búfer en las funciones TO_TIMESTAMP_TZ y TZ_OFFSET, así como en el parámetro DIRECTORY de la función BFILENAME, todos ellos podrán ser empleados para la ejecución de código arbitrario.

Para evitar estos problemas se recomienda la instalación de los parches 2620726, 2642439, 2642267 y 2642117 disponibles en http://metalink.oracle.com/


Antonio Ropero
antonior@hispasec.com


Más información:

Buffer Overflow in ORACLE.EXE binary of Oracle9i Database Server
http://otn.oracle.com/deploy/security/pdf/2003alert51.pdf

Buffer Overflow in TO_TIMESTAMP_TZ function of Oracle9i Database Server
http://otn.oracle.com/deploy/security/pdf/2003alert50.pdf

Buffer Overflow in TZ_OFFSET function of Oracle9i Database Server
http://otn.oracle.com/deploy/security/pdf/2003alert49.pdf

Buffer Overflow in DIRECTORY parameter of Oracle9i Database Server
http://otn.oracle.com/deploy/security/pdf/2003alert48.pdf

miércoles, 12 de febrero de 2003

Desbordamiento de búfer en el cmd.exe de Windows NT/2000

cmd.exe se ve afectado por un fallo al procesar el comando cd con un
nombre de ruta largo. En Windows NT 4.0 esto puede provocar un
desbordamiento de búfer, mientras que bajo Windows 2000 provocará un
fallo en el proceso del archivo batch.

cmd.exe es el intérprete de comandos para la familia de sistemas
operativos Windows NT. También se emplea para procesar archivos .bat y
.cmd.

El sistema de archivos NTFS permite la creación de rutas de longitud
prácticamente ilimitada, pero la API de Windows no permite rutas mayores
de 256 bytes. Según la documentación de la API de Windows se puede
evitar la comprobación de la ruta solicitada con el prefijo \\?\ para el
nombre de archivo.

El cmd.exe de Windows NT 4.0 se ve afectado por un desbordamiento de
búfer en el comando CD si la ruta destino es mayor de 256. Esta
vulnerabilidad puede ser explotada fácilmente para lograr la ejecución
de código.

El cmd.exe de Windows 2000 no se ve afectado por un desbordamiento de
búfer, sin embargo si se cambia a un directorio mayor de 256 caracteres
cmd.exe quedará encerrado en dicho directorio, impidiendo cambiar a
cualquier otro (fallará incluso el comando cd..). Esto puede provocar un
ataque de denegación de servicio contra scripts de mantenimiento.

Se puede realizar una prueba de concepto con el siguiente archivo batch:

@echo off
SET
A=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
SET B=BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
mkdir \\?\c:\%A%
mkdir \\?\c:\%A%\%A%
mkdir \\?\c:\%A%\%B%\
c:
cd \
cd AAAAAAAAAAAA*
cd AAAAAAAAAAAA*
cd BBBBBBBBBBBB*
cd ..


Antonio Ropero
antonior@hispasec.com


Más información:

Windows NT 4.0/2000 cmd.exe long path buffer overflow/DoS
http://www.security.nnov.ru/search/document.asp?docid=4063

martes, 11 de febrero de 2003

Vulnerabilidad en el análisis de URL en Apache Tomcat

Apache Tomcat es un contenedor de servelts utilizado como implementación
de referencia de las tecnologías de servlets Java y JSP (JavaServer
Pages). Se ha descubierto la existencia de un problema de seguridad que
puede ser utilizado para visualizar archivos teóricamente restringidos o
el código fuente de las páginas JSP.

Tomcat puede funcionar como servidor web independiente o bien integrado
dentro de otros servidores web como el propio Apache, Netscape o incluso
IIS. Existen actualmente varias ramas de desarrollo, siendo la versión
3.3.x la que se aconseja utilizar en entornos de producción, al ser la
más estable.

Se ha descubierto la existencia de dos vulnerabilidades en las versiones
anteriores a la 3.3.1 que pueden ser utilizadas por un atacante remoto
para visualizar el contenido de directorios (independientemente de la
existencia de un archivo índice) así como la visualización del contenido
de archivos y directorios cuyo acceso en teoría está restringido.
También puede utilizarse la vulnerabilidad para obtener el código fuente
de los archivos JSP.

La vulnerabilidad radica en las comprobaciones que realiza Tomcat en las
peticiones HTTP para determinar la posible existencia de caracteres
nulos o barras invertidas (\), lo que puede ser aprovechado por el
atacante para saltarse los mecanismos de restricción de acceso y la
protección del código fuente de los archivos JSP.

Una forma fácil de verificar si un servidor es vulnerable consiste en
ejecutar esta orden, utilizando perl y netcat:

$ perl -e 'print "GET /\x00.jsp HTTP/1.0\r\n\r\n";' | nc servidor_web 8080

Si el servidor Tomcat es vulnerable, como resultado de esta petición
obtendremos un listado de todos los archivos existentes en el directorio
raíz del servidor (independientemente de la existencia de un archivo
índice en dicho directorio).

El acceso a los archivos restringidos puede verificarse mediante:

$ perl -e 'print "GET /admin/WEB-INF\\classes/ContextAdmin.java\x00.jsp
HTTP/1.0\r\n\r\n";' | nc servidor_web 8080

(escribir la orden en una única línea).

Como respuesta a esta petición, el servidor web devolverá el contenido
del archivo ContextAdmin.java

En lo que se refieren a la obtención del código fuente de los archivos
JSP:

$ perl -e 'print "GET /examples/jsp/cal/cal1.jsp\x00.html
HTTP/1.0\r\n\r\n";' |
nc servidor_web 8080

(escribir la orden en una única línea).

visualiza el código fuente del archivo cal1.jsp, uno de los ejemplos
incluidos en la distribución de Tomcat.

Como puede observarse con los ejemplos incluidos, es realmente una tarea
trivial aprovecharse de esta vulnerabilidad. Por tanto, conviene
actualizar lo antes posible cualquier versión anterior de Tomcat 3.3.x a
la nueva versión 3.3.1a.


Xavier Caballé
xavi@hispasec.com



lunes, 10 de febrero de 2003

Estados Unidos se prepara para la "ciber-guerra"

Según publica "The Washington Post", el presidente de los Estados Unidos
ha firmado una directiva secreta en la que ordena al gobierno
desarrollar, por primera vez, un plan nacional que fijará cuando y como
lanzar ciber-ataques contra las redes informáticas del 'enemigo'.

Según esta información, el Pentágono está actualmente preparando los
planes para establecer todos los pasos necesarios para desarrollar una
actuación hostil contra la infraestructura informática de un país
enemigo. Se compara esta directiva con la existente para el uso del
armamento nuclear, que establece las situaciones en las que puede
utilizarse dicho armamento, la selección de objetivos que se consideren
legítimos y quien debe autorizar un ataque de este tipo.

Evidentemente no se conocen los detalles concretos del plan
norteamericano para la "ciber-guerra", ya que constituye un preciado
secreto militar. El periódico norteamericano indica que todo el
desarrollo se ha realizado internamente por organismos públicos
(Pentágono, CIA, FBI y NSA) y que el mes pasado se solicitó por primera
vez la opinión de expertos externos, en una reunión celebrada en el MIT.
De acuerdo con la noticia, diversos investigadores expresaron sus
reservas en participar en este tipo de planes bélicos.

Por lo poco que se conoce, las intenciones del ejército norteamericano
pasan por utilizar técnicas de asalto informático para acceder a los
sistemas que controlan los aspectos básicos de la infraestructura de un
país: comunicaciones, transporte, energía y otros servicios básicos. Una
vez obtenido el acceso, se utilizarían armas informáticas para destruir
estos sistemas.

Evidentemente una acción de este tipo es extremadamente hostil e
incumple todas las convenciones internacionales. No está de más recordar
que, de acuerdo con la convención de Ginebra de 1864, durante el
desarrollo de un conflicto militar los ataques deben limitarse
únicamente contra los "combatientes y los objetivos militares"
prohibiendo expresamente las armas que atacan indiscriminadamente tanto
a civiles como a militares.

Así, por ejemplo, lanzar un ataque contra una estación generadora de
electricidad puede provocar que las defensas militares dejen de
funcionar. Pero también hay una gran probabilidad que esto afecte
negativamente a la población civil, por ejemplo dejando un hospital sin
electricidad.


Xavier Caballé
xavi@hispasec.com



domingo, 9 de febrero de 2003

Revelación de información en Majordomo

Existe una vulnerabilidad en Majordomo que permite la obtención de los
suscriptores de las listas de correo, incluso cuando por configuración
no se permite realizar esta operación.

Majordomo es un programa para la administración de las listas de
discusión que realiza las tareas de administración (alta y baja de
suscriptores de la lista), así como el envío de los mensajes y los
parámetros de distribución de los mensajes: listas moderadas,
distribución de mensajes en modalidad digest, etc.

Hasta hace relativamente poco tiempo era el software de listas de correo
más popular en los entornos Unix, pero últimamente está siendo
sustituido por otros programas más modernos que, por ejemplo, permite al
usuario administrar las suscripciones a través de una interfaz web. No
obstante, existen todavía múltiples listas de distribución que son
controladas por Majordomo.

Por defecto, Majordomo permite a cualquier persona obtener la lista de
direcciones suscritas a la lista enviando un mensaje con la orden "WHO
[nombre_lista]" a Majordomo. No obstante, para proteger la privacidad de
los suscriptores y evitar la recolección de direcciones para el envío de
spam, generalmente en la configuración de la lista se restringe el
acceso a esta relación a los suscriptores de la lista o, más
habitualmente, a únicamente el administrador.

Se ha descubierto la existencia de una vulnerabilidad que puede ser
utilizada para obtener la relación de suscriptores, incluso cuando por
configuración se ha deshabilitado la orden WHO.

Si en la configuración de la lista se mantiene la posibilidad de
utilizar la orden "WHICH" (y por defecto, esta opción está activa)
cualquier persona puede obtener la relación de suscriptores en las
diversas listas existentes enviando un mensaje que contenga cualquiera
de estas dos órdenes:

which @
which .

Para hacer uso de esta vulnerabilidad no es preciso estar suscrito a
ninguna de las listas existentes en el servidor atacado. Esta
vulnerabilidad afecta a todas las versiones existentes de Majordomo,
incluyendo las versiones alpha de Majordomo 2.

Para evitar el robo de la lista de suscriptores, aconsejamos revisar la
configuración de todas las listas y en aquellas donde esté habilitada la
orden WHICH, ésta debería deshabilitarse. Alternativamente, se ha
publicado un parche para el código fuente de Majordomo 1.9.5:

--- majordomo.orig Mon Feb 3 13:23:45 2003
+++ majordomo Mon Feb 3 13:23:23 2003
@@ -624,6 +624,11 @@

sub do_which {
local($subscriber) = join(" ", @_) || &valid_addr($reply_to);
+ if ($subscriber !~
/^[0-9a-zA-Z\.\-\_]+\@[0-9a-zA-Z\.\-]+\.[a-zA-Z]{2,3}$/) {
+
+ &log("which abuse -> $subscriber passed as an argument.");
+ exit(0);
+ };
local($count, $per_list_hits) = 0;
# Tell the requestor which lists they are on by reading through all
# the lists, comparing their address to each address from each list

Una vez aplicado este parche, Majordomo ignorará cualquier orden WHICH
que no contenga como parámetro una dirección de correo electrónico.
(WHICH se utiliza para determinar las listas de correo a las en las que
está suscrita una dirección de correo electrónico).

Los usuarios de Majordomo 2 deberán obtener la última versión disponible
en el servidor CVS.


Xavier Caballé
xavi@hispasec.com


Más información:

Majordomo
http://www.greatcircle.com/majordomo

Majordomo info leakage (mailing list exposute), all versions
http://www.securitybugware.org/mUNIXes/5971.html

Majordomo Mailing List Default Configuration Discloses List E-mail
Addresses to Remote Users
http://www.securitytracker.com/alerts/2003/Feb/1006040.html

Majordomo Disclosure of Subscribed Email Addresses
http://www.secunia.com/advisories/8010/

sábado, 8 de febrero de 2003

Diversas vulnerabilidades en Opera 7.0

Se han detectado diversas vulnerabilidades en la versión 7.0 del
navegador Opera. En total se describen tres vulnerabilidades críticas,
ya que pueden ser utilizadas para acceder al contenido de cualquier
archivo del disco del usuario; las dos vulnerabilidades restantes
afectan a la privacidad del usuario, al revelar las URL que ha visitado.

Opera es un navegador web desarrollado por una empresa noruega y destaca
por su velocidad y reducido tamaño, sin por ello carecer de las
prestaciones disponibles en otros navegadores modernos. Tradicionalmente
ha sido un programa que ha tenido los preceptos de seguridad como parte
fundamental de su diseño, siendo raras las vulnerabilidades de seguridad
que se han documentado.

A principios del presente mes de febrero se anunció la existencia de
diversas vulnerabilidades de seguridad que afectaban únicamente la
versión 7.0 (todas las versiones anteriores están libres de los
problemas descritos). Algunas de estas vulnerabilidades pueden
clasificarse como críticas ya que permiten el acceso completo, en
modalidad de lectura, al sistema de archivos del usuario de Opera.

* Vulnerabilidad en el modelo de seguridad de Opera

Para evitar que mediante JavaScript una página pueda acceder a la
información de otro dominio, Opera implementa un modelo de seguridad que
debería impedir estos traspases de información.

No obstante, se han descubierto diversas vulnerabilidades en este modelo
de seguridad: se puede acceder y ejecutar a funciones JavaScript de
diferentes dominios; las funciones JavaScript se ejecutan con las
credenciales del dominio del usuario y no las correspondientes al
dominio de origen; es posible ignorar las propiedades y métodos (tanto
nativos como definidos por el usuario) en otras ventanas.

La utilización de estas vulnerabilidades puede permitir, desde una
página especialmente formateada, acceder en modalidad de lectura a
cualquier archivo existe en la máquina del usuario.

* El fantasma de la Ópera

La consola de JavaScript de Opera utiliza tres archivos que se
encuentran en el directorio raíz del programa. La función de la consola
es mostrar las excepciones no controladas que se producen en cada
sesión.

La consola incluye el código necesario para visualizar las URL como
enlaces activos. No obstante, debido a la insuficiencia de los controles
aplicados, un atacante puede inyectar sus propios atributos de código al
enlace. Con un poco de manipulación, el atacante puede aprovechar esta
vulnerabilidad para forzar la ejecución de código script arbitrario.

* Tratamiento de imágenes en Opera

Opera 7.0 no realiza ninguna comprobación en una URL que apunta al disco
del usuario (file://) para la visualización de un gráfico. Como
consecuencia de esta ausencia de controles, un atacante puede inyectar
código en la URL que le permite acceder al contenido de cualquier
archivo residente en la máquina del usuario.

* Acceso a la URL anterior y siguiente

Opera 7.0 no protege el acceso desde JavaScript al histórico de URL
visitadas por el usuario. Así un atacante puede obtener la última URL
visitada por el usuario, así como la siguiente (las URL a las que se
accede, respectivamente, con el botón "Atrás" y "Adelante" del
navegador).

* Obtención de las URL que ha visitado el usuario

Como en el caso anterior, Opera 7.0 no impide que una función JavaScript
obtenga la relación de todas las URL visitadas por el usuario en una
sesión que provoquen algún tipo de excepción. Como la configuración por
defecto de Opera 7.0 es la de identificarse como Internet Explorer,
muchas páginas web provocan errores. Aprovechando esto y la
vulnerabilidad, el atacante puede identificar fácilmente las URL que ha
visitado el usuario.

Opera ha publicado recientemente la versión 7.01 para Windows que
soluciona todas estas vulnerabilidades.


Xavier Caballé
xavi@hispasec.com



viernes, 7 de febrero de 2003

SDSC Secure Syslog

SDSC Secure Syslog es un nuevo protocolo para el registro de actividad
diseñado para eliminar algunas de las carencias del syslog estándar de
la mayoría de sistemas de Unix, especialmente en lo referente a
rendimiento en grandes redes y a la seguridad.

syslog es el servicio de registro de actividad presente en la mayoría de
sistemas Unix. Originalmente diseñado por la universidad de California
para su sistema BSD UNIX, la versatilidad del mismo lo han convertido en
un componente ubicuo en la mayoría de versiones modernas de Unix. A
pesar de los años que han transcurrido desde la aparición de syslog,
éste ha evolucionado relativamente poco debido a que ha sido siempre un
servicio extremadamente flexible.

No obstante, las versiones clásicas de syslog tienen diversos problemas
cuando son consideradas desde el punto de vista de la seguridad: la
inexistencia de mecanismos de autenticación fuerte, la utilización de
UDP para la transmisión de los mensajes, la inexistencia de una
estructuración estándar en los mensajes y los problemas de rendimiento
cuando el servicio se encuentra en redes de gran tamaño.

Para resolver estos problemas con el tiempo han aparecido diversas
alternativas a syslog como syslog-ng y msyslog, entre otros. Estas
alternativas se han centrado en la posibilidad de utilizar el protocolo
TCP para la transmisión de los mensajes, funciones avanzadas de filtrado
y la posibilidad de registrar los mensajes directamente en una base de
datos SQL. msyslog además permite firmar digitalmente los registros.

SDCS Secure Syslog, desarrollado por el San Diego Supercomputer Center y
distribuido bajo una la licencia que permite su utilización sin
finalidades comerciales, es la primera implementación de syslog basada
en el RFC 3195. Ofrece plena compatibilidad descendente con las
versiones tradicionales de syslog y, además, añade una serie de
prestaciones especialmente diseñadas para dar soporte a un gran volumen
de tráfico y a los requerimientos de seguridad:

-Utilización de un formato estándar de mensaje, siempre que sea posible.

-Utilización de TCP con posibilidad de autenticación. Esto se consigue
encapsulando los paquetes del protocolo BEEP. Cifrado del tráfico.

-Utilización del DNS para descubrir la existencia de servidores que
actúan como repositorio de los registros de actividad.

-Autenticación de los mensajes como paso previo a su almacenamiento.

-Diseñado para soportar ataques de denegación de servicio así como
responder de forma predecible ante posibles desbordamientos de búfer.

-Diseñado para dar soporte a millones de registros por hora.



Xavier Caballé
xavi@hispasec.com


Más información:

SDSC Secure Syslog Home Page
http://security.sdsc.edu/software/sdsc-syslog/

SCSC Secure Syslog
http://slashdot.org/article.pl?sid=02/12/05/1554209

BEEP, a new Internet standards-track protocol framework for new Internet
Applications
http://www.beepcore.org/

Reliable Delivery for syslog
http://www.ietf.org/rfc/rfc3195.txt
ftp://ftp.rfc-editor.org/in-notes/rfc3195.txt

The BSD Syslog Protocol
ftp://ftp.rfc-editor.org/in-notes/rfc3164.txt

syslog-ng
http://www.balabit.hu/en/downloads/syslog-ng/

msyslog
http://sourceforge.net/projects/msyslog/

metalog
http://metalog.sourceforge.net/

jueves, 6 de febrero de 2003

Nuevo parche acumulativo para Internet Explorer

Microsoft publica un nuevo parche acumulativo para las versiones 5.01,
5.5 y 6.0 de Internet Explorer. Además de los parches anteriores, se
corrigen dos vulnerabilidades que pueden permitir a un atacante ejecutar
código malévolo en la máquina del usuario.

El nuevo parche publicado por Microsoft es del tipo acumulativo; es
decir, se incluyen todas las actualizaciones para los diversos problemas
de seguridad en Internet Explorer conocidos hasta la fecha. Por tanto,
una vez aplicado podemos tener la certeza de que el navegador dispone de
todas las actualizaciones publicadas hasta el día de hoy.

Adicionalmente, el nuevo parche soluciona dos nuevos problemas de
seguridad, calificados como críticos ya que pueden ser utilizados por un
atacante para forzar la ejecución de código en la máquina del usuario de
Internet Explorer.

La primera de las nuevas vulnerabilidades se encuentra en los mecanismos
de seguridad que utiliza Internet Explorer para impedir la comunicación
entre dos ventanas que estén accediendo a dominios diferentes. Debido a
que los mecanismos existentes no son suficientes, existe la posibilidad
de que un atacante consiga ejecutar código arbitrario en la máquina del
usuario vulnerable (enviando un programa o forzando la ejecución de un
ejecutable presente en la máquina del usuario). Para aprovecharse de
esta vulnerabilidad el atacante debe convencer al usuario que visite una
página web especialmente preparada.

La segunda de las nuevas vulnerabilidades se encuentra en la forma en
que Internet Explorer utiliza la función showHelp() para visualizar una
página HTML de ayuda. La vulnerabilidad permite a un atacante utilizar
esta función para abrir una página sin que se realicen las
comprobaciones de seguridad suficientes.

Como en el caso anterior, esta segunda vulnerabilidad también puede ser
aprovechada para ejecutar código o bien acceder a la información
almacenada en la máquina del usuario.

Una vez aplicado este parche acumulativo, showHelp() dejará de
funcionar. Microsoft ha publicado también una nueva versión del motor de
ayuda HTML que utiliza un nuevo método para acceder a las páginas HTML
de ayuda.

El parche publicado por Microsoft puede instalarse en las máquinas que
ejecuten Windows 2000 Service Pack 3 con Internet Explorer 5.01 y
Service Pack 3; en Internet Explorer 5.5 con Service Pack y en todas las
versiones de Internet Explorer 6.0. Está disponible en la siguiente
dirección:

http://www.microsoft.com/windows/ie/downloads/critical/810847/default.asp

La nueva versión del motor de ayuda HTML (811630), necesaria para
visualizar las páginas HTML de ayuda una vez instalado el parche
acumulativo, en el momento de escribir este boletín sólo puede
instalarse a través del servicio Windows Update.


Xavier Caballé
xavi@hispasec.com


Más información:

Boletín de seguridad de Microsoft (MS03-004)
Cumulative Patch for Internet Exploter (810847)
http://www.microsoft.com/technet/security/bulletin/MS03-004.asp

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

Improper Cross Domain Security Validation with dialog box
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1326

Improper Cross Domain Security Validation with ShowHelp functionality
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1328

Dangerous security hole, IE needs patching again
http://www.theinquirer.net/?article=7640

IE security disabled via showHelp("file:") cross site/zone scripting
http://www.securitybugware.org/NT/5976.html

If it's Thursday it must be IE patching day
http://www.theregister.co.uk/content/55/29208.html

showHelp("file:") disables security in IE - Sandblad advisory #11
http://online.securityfocus.com/archive/1/310684

miércoles, 5 de febrero de 2003

Actualización por vulnerabilidad en Windows XP

Microsoft publica una actualización para Windows XP para cubrir una
vulnerabilidad en el componente Windows Redirector por la cual un
atacante local puede elevar sus privilegios en el sistema.

El Windows Redirector se usa como un cliente Windows para el acceso a
archivos, tanto si son locales como remotos, sin preocuparse por los
protocolos de red subyacentes en uso. Por ejemplo, el asistente "Add a
Network Place" (añadir un sitio de red) o el comando NET USE pueden
emplearse para mapear un recurso de red compartido como una unidad
local, y el Windows Redirector tratará el rutado de la información hacia
y desde el recurso compartido.

Existe una vulnerabilidad de seguridad en la implementación del Windows
Redirector en Windows XP debido al uso de un búfer sin comprobar para
recibir información de los parámetros. Un atacante podrá provocar un
fallo del sistema e incluso la ejecución de código si envía datos
específicamente construidos al Windows Redirector.

Para evitar este problema Microsoft publica los siguientes parches:
Windows XP 32-bit Edition:
http://microsoft.com/downloads/details.aspx?FamilyId=33DABD1F-505E-48ED-B9BD-CDAC0F8A2BC1&displaylang=en

Windows XP 64-bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=A2258F4E-9A69-4537-9469-0DDEB4BB76F8&displaylang=en


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin MS03-005
Unchecked Buffer in Windows Redirector Could Allow Privilege Elevation (810577)
http://www.microsoft.com/technet/security/bulletin/ms03-005.asp

What You Should Know About Microsoft Security Bulletin MS03-005
Security Update for Microsoft Windows XP
http://www.microsoft.com/security/security_bulletins/ms03-005.asp

martes, 4 de febrero de 2003

Diversos problemas en BEA WebLogic

Se ha anunciado la existencia de diversos problemas de seguridad en el
servidor de aplicaciones BEA WebLogic.

Los problemas encontrados afectan a las versiones 5.x, 6.x y 7.x, el
primero de ellos consiste en que WebLogic en algunos casos da a dos
usuarios la misma sesión. El problema puede provocar una replicación de
otra sesión.

Los parches que corrigen este problema se encuentran en las siguientes
direcciones:

WebLogic Server y Express 5.1
ftp://ftpna.beasys.com/pub/releases/security/CR094773_510sp13.jar

WebLogic Server y Express 6.0
ftp://ftpna.beasys.com/pub/releases/security/CR094773_60sp2rp3.jar

WebLogic Server y Express 6.1
ftp://ftpna.beasys.com/pub/releases/security/CR094773_61sp4.jar

WebLogic Server y Express 7.0 y 7.0.0.1
ftp://ftpna.beasys.com/pub/releases/security/CR094773_70sp1.jar


El segundo de los problemas consistente en una denegación de servicio
cuando el servidor recibe determinadas peticiones HTTP.

Los parches que corrigen este problema se encuentran en las siguientes
direcciones:

WebLogic Server y Express 5.1 en Microsoft NT o Windows 2000
Actualizar a Service Pack 13

WebLogic Server y Express 6.0 en Microsoft NT o Windows 2000
ftp://ftpna.bea.com/pub/releases/security/CR089803_600sp2rp3.jar

WebLogic Server y Express 6.1 en Microsoft NT o Windows 2000
Actualizar a Service Pack 4

WebLogic Server y Express version 7.0 o Microsoft NT o Windows 2000
ftp://ftpna.bea.com/pub/releases/security/CR089803_70sp1.jar


El último de los problemas reside en un almacenamiento inseguro de la
contraseña, ya que cuando esta se almacena en texto claro en el
servidor. Este problema sólo afecta a WebLogic 7.0 y se soluciona con la
aplicación del siguiente parche:
ftp://ftpna.beasys.com/pub/releases/security/CR091911_70sp1.jar


Antonio Ropero
antonior@hispasec.com


Más información:

Patch available to prevent session sharing
http://dev2dev.bea.com/resourcelibrary/advisoriesdetail.jsp?highlight=advisoriesnotifications&path=components%2Fdev2dev%2Fresourcelibrary%2Fadvisoriesnotifications%2FBEA03-26.htm

Patch available for DOS attack
http://dev2dev.bea.com/resourcelibrary/advisoriesdetail.jsp?highlight=advisoriesnotifications&path=components%2Fdev2dev%2Fresourcelibrary%2Fadvisoriesnotifications%2FBEA03-14.htm

Patch available to protect password
http://dev2dev.bea.com/resourcelibrary/advisoriesdetail.jsp?highlight=advisoriesnotifications&path=components%2Fdev2dev%2Fresourcelibrary%2Fadvisoriesnotifications%2FBEA03-25.htm

lunes, 3 de febrero de 2003

Antivirus: el efecto "zoo"

A la pregunta de "¿cuál sería el mejor antivirus?", una respuesta
bastante obvia sería "el que detecte todos los virus". Afortunadamente
atrás quedaron las campañas de publicidad engañosas que prometían
protección 100% contra virus conocidos y desconocidos. Así que hoy
día, demostrado una y otra vez que no pueden ofrecer garantías de
protección proactiva contra especímenes nuevos, la respuesta podría
quedar en "el que detecte más número de virus". Falso. Es más, el
enfoque de "cuantos más, mejor" nos conduce de forma irreversible
hacia peores productos antivirus. ¿Hora de cambiar?

En este artículo no pretendo entrar en nuevas tecnologías proactivas
que podrían, sino sustituir de inmediato, al menos complementar los
actuales sistemas por detección de firmas. Ya no sólo como evaluador,
sino como desarrollador en Hispasec de algunas pruebas de concepto
sobre nuevas tecnologías antivirus, soy consciente de que aun queda
mucho camino por recorrer antes de que puedan equipararse a los
sistemas actuales en cuanto a fiabilidad y facilidad. Esto no quita
que existan algunas funcionalidades proactivas que no estarían de más
en los actuales antivirus, y que algunas casas ya empiezan a
implementar.

En definitiva, se trata de analizar el efecto negativo que, en los
actuales sistemas antivirus de detección por firmas, provoca algunas
prácticas que persiguen adulterar y engordar de forma artificial las
estadísticas de virus reconocidos de cara a la galería.


Las colecciones "zoo"

En la mayoría de certificaciones y comparativas se suele enfrentar
los productos antivirus contra varias colecciones de muestras
infectadas. El porcentaje de aciertos en las diferentes colecciones
suele ser el indicador más determinante a la hora de valorar un
producto.

Las colecciones pequeñas, de virus más significativos y activos, como
la "InTheWild", apenas presentan diferencias de resultados entre la
mayoría de los productos y, más que un indicador comparativo, sirve
como mínimo exigible.

Para marcar diferencias en las comparativas, y también como prueba de
fuego en las certificaciones, se suele utilizar la llamada colección
"zoo", que básicamente consiste en un conjunto de todas las muestras
infectadas que se posee.

La "zoo" comprende, además de los virus más relevantes y novedosos,
toda muestra que el evaluador haya conseguido recolectar a lo largo
de su carrera, desde los primeros virus que aparecieron, de los que
hoy día ya no existen pruebas de infecciones reales, hasta aquellos
que nunca han visto la luz ni infectado a nadie, pero que forman
parte de pruebas de laboratorio o colecciones privadas.

Llegados a este punto, el usuario debe ser consciente que de los
60.000 o 70.000 virus que hoy día algunos antivirus afirman detectar,
tan sólo unos cientos representan el 99% de las infecciones reales
durante un año.

La necesidad de que un antivirus detecte un virus de los años 80 que
hoy día no tiene posibilidades de propagación bajo Windows, o un
virus que nunca ha salido a la luz y no ha infectado a nadie, puede
llegar a ser discutible. Aunque las comparaciones y extrapolaciones
en este campo no son buenas, es como si alguien se vacunara contra
una enfermedad ya erradicada o contra un virus biológico de
laboratorio, por si algún día resulta que hay un brote.

Pero la realidad es que la posibilidad, por remota que sea, existe,
y el deber de un antivirus es ofrecer el mayor grado de protección
posible, en especial si se trata de virus conocidos. Así que hasta
el momento, nada que objetar.


Adulteraciones en las "zoo"

El problema real de las colecciones "zoo" es que no están depuradas.
Es decir, existen muestras consideradas virus (o cualquier otra
variante de malware, como gusanos, troyanos, etc.) que en realidad
no lo son, ni presentan ningún efecto nocivo ni dañino. En definitiva,
no tendrían que formar parte de la colección, ni tendrían que ser
detectadas por los antivirus.

Para la confección de las propias comparativas antivirus de Hispasec,
revistas especializadas, así como para análisis e informes técnicos,
necesitamos contar con el mayor número de muestras posibles para
realizar nuestro trabajo. Entre otras fuentes, regularmente recorremos
las webs de creadores de virus y coleccionistas que permiten la
descarga de muestras de forma pública a través de Internet y, por
tanto, son especímenes que potencialmente podrían llegar a cualquier
usuario.

Una de las tareas más tediosas para mantener la colección de muestras
de Hispasec no es la recolección, sino la comprobación de las mismas.
Afortunadamente a lo largo de los años hemos desarrollado varias
herramientas que de forma automática nos hacen las primeras cribas
y son capaces de descubrir las muestras falsas más comunes.

Sin embargo, son muchas las comparativas, incluida algunas
certificaciones, que a juzgar por algunos resultados no realizan
una depuración de las colecciones. Como resultado, sus colecciones
"zoo" están adulteradas con muestras que no son virus, y ello se
extrapola a los indicadores que obtienen los diferentes productos
antivirus.

Lo peor aun es que la mayoría de las casas antivirus, tal vez
condicionadas por estas comparativas y certificaciones donde se
podían ver perjudicadas, han optado por incluir en su base de datos
de firmas esas falsas muestras como si fueran auténticos virus.
Otra posibilidad podría ser la inversa, que las casas antivirus
hubieran sido las primeras en incorporarlos como virus a sus bases
de datos y que las comparativas los incluyeran a posteriori en
sus colecciones al comprobar que algún antivirus las reconocían
como virus. Independientemente de si fue primero el huevo o la
gallina, el caso es que el circulo vicioso no hace más que aumentar.

Como dato, durante la comparativa antivirus que llevé a cabo en
1999 para PCActual e Hispasec, introducí un test inédito hasta la
fecha, que consistió en enfrentar a los antivirus contra una serie
de archivos representativos que habían quedado fuera de nuestra
colección durante las cribas de recopilación al comprobarse que
no eran virus reales. Los resultados son reveladores:
http://www.hispasec.com/comp_avs.asp?id=25

En realidad hay muchos otros tipos de muestras que suelen ser
incluidas en las bases de datos de firmas antivirus y que en
realidad no tienen ningún efecto dañino, desde binarios que
ni siquiera pueden llegar a ejecutarse, porciones de virus que
están corruptos y no pueden activarse, etc.


El efecto "zoo"

¿Cómo repercute el número de firmas que reconoce un motor antivirus
en su rendimiento? Parece claro que existe una relación directa,
a mayor número de firmas a chequear, mayores recursos necesitará,
y la velocidad de proceso será menor, lo que perjudica al resto
de procesos o aplicaciones que existan en el sistema.

El hecho de que los antivirus reconozcan virus falsos, además de
la publicidad engañosa que pueda generar o la búsqueda de buenos
resultados artificiales en comparativas y certificaciones de dudosa
calidad, tiene un efecto negativo en el comportamiento del propio
antivirus que puede penalizar el rendimiento del sistema e incluso
hacer peligrar la seguridad del cliente.

La solución aunque pueda parecer sencilla, bastaría con depurar las
firmas de detección de los antivirus, tiene efectos negativos
inmediatos a nivel comercial: podrían verse perjudicados en
comparativas y certificaciones que cuenten con muestras falsas. Es la
pescadilla que se muerde la cola.

Las casas antivirus se encuentran en muchas ocasiones en la
encrucijada de diseñar sus productos pensando en la protección real
del usuario o en los requisitos de los evaluadores. Paradójicamente,
además de no coincidir en algunas ocasiones, pueden existir incluso
intereses opuestos. Normalmente se opta por un punto intermedio,
intentar acometer los requerimientos de ambos, aunque a costa del
detrimento en la optimización del producto.

Llegados a este punto, no debemos caer en la tentación de arrojar
sobre las espaldas de las casas antivirus toda la responsabilidad.
De hecho, buena parte de esta percepción errónea de lo que debe ser
un buen antivirus es achacable a las revistas especializadas y
analistas que nos dedicamos a crear opinión sobre las soluciones
antivirus.

Si más de una vez he dicho que muchos productos antivirus se
encuentran anclados en el pasado, por no integrar nuevas tecnologías
de detección más allá de las firmas, las comparativas y
certificaciones están mucho peor. Uno de los casos más sonados fue
el de la comparativa antivirus de CNET en 2001, entre otros
despropósitos, llegaron a utilizar simuladores de virus en vez
de muestras reales para algunos tests. Por lo demás, la mayoría
siguen basando su modelo de evaluación en arcaicas pruebas de
detección ITW y Zoo.


Soluciones

Las comparativas y certificaciones deben de evolucionar, incluyendo
nuevos tests acorde con las características de las nuevos especímenes
que aprovechan Internet para su propagación, así como evaluaciones
que contemplen las nuevas tecnologías antivirus que se están
incorporando. Por otro lado, deberían de incorporar mecanismos para
la depuración de sus colecciones para evitar el efecto "zoo",
incluyendo tests de detección de falsos virus cuyos indicadores se
relacionen con tests de rendimiento del motor.

Los antivirus deberían de dejar de utilizar el concepto de número
de virus detectados como arma de marketing, ya que no tiene ningún
sentido que sigan en una guerra de cifras que de sobra saben no
tiene ningún valor real y que tarde o temprano terminará por
perjudicarles. Además, deberían optimizar su base de datos de firmas
para reconocer sólo los especímenes que realmente pueden llevar
a cabo acciones dañinas, eliminando los falsos virus. En caso de
verse perjudicados en comparativas o certificaciones que utilicen
colecciones "zoo" no depuradas, con muestras falsas, deberían
denunciar públicamente los resultados.

Los usuarios deben de tomar conciencia de que el número total de
virus que dice reconocer un antivirus es un dato sin ningún valor.
Además de todo lo comentado con anterioridad respecto a los
falsos virus, la propia tecnología de detección por firmas lleva
a resultados dispares. Por ejemplo, dado 10 variantes de un mismo
virus, un producto puede necesitar 10 firmas diferentes mientras
otro puede detectar las 10 variantes de forma más genérica con
sólo 2 firmas. A efectos de marketing, el primero sumará 10 virus
mientras que el segundo contará sólo 2, sin embargo la detección
del segundo producto es más genérica y efectiva. Tan sólo las
comparativas con colecciones depuradas pueden ofrecer las
diferencias reales entre el poder de detección de los distintos
motores antivirus, nunca el número de virus que el propio
producto anuncia.


Bernardo Quintero
bernardo@hispasec.com