sábado, 30 de noviembre de 2002

Desbordamiento de búfer en el servidor de fuentes X de Solaris

Se ha descubierto un desbordamiento de búfer en el servidor de fuentes X
de Solaris, que puede ser explotado de forma remota.

El servidor de fuentes de X Window (XFS) del sistema operativo Solaris
es el componente del sistema encargado del envío de los tipos de letras
a las estaciones X que conectan con el servidor.

En determinadas configuraciones del sistema operativo, este servicio se
encuentra activo. Para las comunicaciones entre el servidor X y las
estaciones se utiliza el puerto 7100/tcp.

Se ha descubierto la existencia de un desbordamiento de búfer, que puede
ser explotado de forma remota por un atacante para ejecutar código
arbitrario en el sistema vulnerable. Esto, conjuntamente con otras
vulnerabilidades, puede ser utilizado por el atacante para obtener el
privilegio de root.

También puede utilizarse esta vulnerabilidad para detener
inesperadamente el servicio, provocando por tanto la denegación del
servicio.

Las versiones de Solaris afectadas por el problema son las siguientes:
en la plataforma SPARC las versiones 2.5.1, 2.6, 7, 8 y 9. En la
plataforma Intel las versiones 2.5.1, 2.6, 7 y 8.

Sun tiene prevista la publicación, en los próximos días, de parches para
solucionar el problema. Hasta la disponibilidad de los mismos deberán
aplicarse las siguientes soluciones temporales:

* Configurar los sistemas de protección perimetral de la red para
filtrar cualquier tráfico con destino al puerto 7100/tcp.

* Deshabilitar en la configuración de inetd el servicio XFS. Para ello,
comentar la línea correspondiente al servicio fs:

# fs stream tcp wait nobody /usr/openwin/lib/fs.auto fs

y reiniciar el servicio inetd


Xavier Caballe
xavi@hispasec.com



viernes, 29 de noviembre de 2002

Se publica una versión actualizada de SAMBA

El equipo SAMBA acaba de publicar la versión 2.2.7 de este software, que
soluciona un problema de seguridad potencialmente peligroso.

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

Las versiones 2.2.2 a 2.2.6 de Samba, inclusive, contienen un problema
de seguridad que, potencialmente, permitiría que un usuario remoto
ejecutase código arbitrario como administrador o "root".

El problema radica en el mecanismo de cambio de clave por parte de los
usuarios. Un atacante remoto podría enviar una petición de cambio de
clave con una clave cifrada de longitud ilegal que, al decodificarse,
puede provocar un desbordamiento de búfer y matar el servidor SAMBA o en
el peor de los casos, permitir la ejecución de código arbitrario en el
servidor con los privilegios del usuario SAMBA, típicamente
administrador o "root".

HispaSec recomienda a todos los administradores de sistemas SAMBA que
actualicen cuanto antes a la versión 2.2.7 de dicho software.


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


Más información:

The Samba Team are pleased to announce Samba 2.2.7
http://www.samba.org/samba/whatsnew/samba-2.2.7.html

Samba Buffer Overflow in User Input Routine May Let Remote Users Execute
Arbitrary Code with Root Privileges
http://www.securitytracker.com/alerts/2002/Nov/1005677.html

(SuSE Issues Fix) Samba Buffer Overflow in User Input Routine May Let
Remote Users Execute Arbitrary Code with Root Privileges
http://www.securitytracker.com/alerts/2002/Nov/1005678.html

(Debian Issues Fix) Samba Buffer Overflow in User Input Routine May Let
Remote Users Execute Arbitrary Code with Root Privileges
http://www.securitytracker.com/alerts/2002/Nov/1005684.html

jueves, 28 de noviembre de 2002

Problemas en RealPlayer

Se han descubierto tres vulnerabilidades de desbordamiento de búfer en
los reproductores RealPlayer y RealOnePlayer que podrán permitir a un
atacante tomar el control de los sistemas afectados.

Si un atacante consigue que el usuario descargue y reproduzca un archivo
maliciosamente creado, podrá provocar un desbordamiento y la
consiguiente caída del reproductor, con la posibilidad de lograr la
ejecución de código y tomar el control del sistema.

El primer problema se produce cuando un archivo smil contiene un número
elevado de caracteres en los metadatos del archivo. El segundo bug
radica en el tratamiento de nombres de archivos largos en una dirección
rtsp://. La tercera vulnerabilidad también radica en un problema en el
tratamiento de archivos con nombres largos, al seleccionar las opciones
"editar información" o "copiar a mi librería".

RealNetworks ha publicado una actualización para cubrir estos problemas.
Si bien, según ha comunicado Mark Litchfield, descubridor del problema,
el parche proporcionado no corrige los problemas adecuadamente, por lo
que estos siguen presentes aun tras su instalación.


Antonio Ropero
antonior@hispasec.com


Más información:

Mulitple Buffer Overflow conditions in RealPlayer/RealOne
http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0211&L=ntbugtraq&F=P&S=&P=2132

RealPlayer Buffer Overrun Vulnerability
http://service.real.com/help/faq/security/bufferoverrun_player.html

RealPlayer security fix is faulty
http://www.theregister.co.uk/content/55/28308.html

RealPlayer patch doesn't work
http://www.silicon.com/public/door?6004REQEVENT=&REQINT1=56566&REQSTR1=silicon.com

Actualización proporcionada por RealNetworks
http://service.real.com/help/faq/security/07092002/skinpatchr11s.rmp

miércoles, 27 de noviembre de 2002

Puerta trasera en Alcatel OmniSwitch 7700 y 7800

Detectado un servicio telnet a la escucha en el puerto TCP/6778 en los
Alcatel OmniSwitch 7700/7800 con Alcatel Operating System (AOS)
versión 5.1.1. La empresa afirma que se trata de un servicio que se
utilizó durante la fase de desarrollo y que por error se ha mantenido
en la versión final distribuida.

El acceso por el servicio telnet, sin necesidad de introducir
contraseña alguna, permitiría a un atacante el acceso con privilegios
administrativos a cualquier dispositivo bajo AOS 5.1.1. Es decir,
control total de forma indiscriminada.

Como medida preventiva se debería bloquear el acceso al puerto TCP
6778 desde el perímetro de la red, mientras que la solución definitiva
para erradicar la puerta trasera requiere la actualización a
AOS 5.1.1.R02 o AOS 5.1.1.R03.


Bernardo Quintero
bernardo@hispasec.com


Más información:

CERT Advisory CA-2002-32 Backdoor in Alcatel OmniSwitch AOS
http://www.cert.org/advisories/CA-2002-32.html

Alcatel OmniSwitch 7700/7800 does not require a password for
accessing the telnet server
http://www.kb.cert.org/vuls/id/181721

OmniSwitch_7000_brief
http://www.ind.alcatel.com/nextgen/OmniSwitch_7000_brief.pdf

CAN-2002-1272
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1272

martes, 26 de noviembre de 2002

La seguridad del software de código abierto puesta en entredicho

Tras el análisis de los avisos de seguridad publicados por el CERT, se
ha puesto en entredicho la seguridad del software de código abierto.

Hace unos días, el pasado 5 de noviembre, nos hacíamos eco aquí mismo de
la publicación de un estudio, realizado por mi2g, donde se realizaba una
cuantificación de las vulnerabilidades de seguridad en los diferentes
sistemas operativos. La conclusión es que "las diferentes versiones de
Windows están afectadas por un 44% de las vulnerabilidades".

Sólo unos días después de la publicación de aquél informe, otra empresa
de consultoría estratégica, Aberdeen Group, publicaba otro informe que
llegaba a unas conclusiones radicalmente diferente: "El software de
código abierto es actualmente la mayor fuente de vulnerabilidades de
seguridad para los usuarios de las tecnologías de la información".

El estudio de Aberdeen Group

El estudio de Aberdeen recientemente publicado realiza un análisis los
avisos emitidos por el CERT durante los años 2001 y 2002, extrayendo
estas conclusiones:

* Durante el año 2001 se publicaron seis avisos con relación a virus
y troyanos que afectaban a los productos de Microsoft. En los diez
primeros meses del 2002, no se ha publicado ninguno.

* En lo que se refiere a Linux y productos de código abierto, durante el
año 2001 sólo se publicó un aviso relacionado con virus y troyanos. En
los diez primeros meses del presente año ya se han publicado dos.

* Los avisos relacionados con dispositivos de la red han pasado de dos
durante el 2001 a seis en lo que va de año.

* Los avisos que afectan al sistema operativo Mac OS X de Apple han
pasado de uno el pasado año a cuatro en los diez primeros meses del
presente año.

* Los cortafuegos y productos de seguridad para los que únicamente se
emitieron dos avisos durante todo el año 2001 ya han registrado siete
avisos entre enero y octubre del presente año.

Con estos datos, para Aberdeen Group algunos mitos de la seguridad
quedan en entredicho. Los productos de Microsoft no son los más
vulnerables que existen y sistemas Unix y Linux, así como los proyectos
de código abierto, son también vulnerables a los efectos de los virus,
gusanos y troyanos.

Igualmente, el nuevo sistema operativo de Apple, gracias a su base
derivada de Unix, con todos sus protocolos y utilidades, pasa a formar
parte del mundo real de las vulnerabilidades.

Todo esto sin olvidar que la creciente incorporación de código de
software abierto en diversos productos (routers, servidores web,
cortafuegos, bases de datos, software de comunicación instantánea y
productos de seguridad) convierte a los mismos en posibles objetivos de
infección y otros efectos de las vulnerabilidades.


Dos estudios, dos conclusiones diferentes... ¿a quién creer?

Tal como ya indiqué al comentar el estudio de mi2g, tomar una simple
suma de incidencias de seguridad tiene un valor informativo
prácticamente nulo. No importa tanto el número, como el impacto real que
tienen estas incidencias.

Personalmente, creo que el problema de la seguridad no está circunscrito
a un modelo de código propietario o código abierto. Querer buscar
deficiencias en un tipo de desarrollo u otro no es otra cosa que marear
la perdiz e intentar despistar al personal... amén de alimentar de
falsos argumentos a los irreductibles defensores de cada bando.

En ambos modelos existen problemas de seguridad. El desarrollo de
software es una tarea humana especialmente compleja y, hasta que no se
demuestre lo contrario, los seres humanos somos falibles y por tanto,
sujetos a cometer errores. Por tanto, no creo que debamos preocuparnos
tanto quién tiene "menos" (en cantidad) problemas sino quien responde
mejor ante el descubrimiento de un problema.

Para mí, personalmente, me interesa más saber cual es el compromiso de
cada fabricante en el desarrollo de actualizaciones y parches, en que
medida informan de los problemas existentes, que problemas 'colaterales'
surgen al aplicar las soluciones publicadas, que nivel de documentación
hay disponible... y otros aspectos similares.

Lo que sí deseo destacar del estudio de Aberdeen es una de las
conclusiones que muestra: Los sistemas con más vulnerabilidades pueden
fácilmente cambiar de un período de tiempo a otro, pero lo que no cambia
es la misma existencia de vulnerabilidades y que éstas están presentes
en todos los sistemas. Por tanto, no importa el sistema operativo que
utilizamos, siempre deberemos estar al tanto de las vulnerabilidades y
que deberemos dedicar cada vez más tiempo a aspectos de seguridad.


Xavier Caballe
xavi@hispasec.com



lunes, 25 de noviembre de 2002

Opciones de seguridad en Linux a través de /proc (II)

Continuamos con la descripción de los parámetros de seguridad de las
máquinas que ejecutan Linux con el sistema de archivos virtual /proc.

Los parámetros que vamos a ver a continuación muestran como podemos
controlar la forma en que un sistema actúa en determinadas
circunstancias. Estos parámetros nos van a ayudar a fortalecer la
seguridad del sistema operativo. Estos parámetros son un complemento a
las medidas de protección perimétricas, como pueden ser los cortafuegos.

Mediante /proc no sólo podemos cambiar estos parámetros. Hay otras
muchas cosas interesantes que podemos hacer, como por ejemplo mejorar el
rendimiento del sistema de archivos, modificar la forma en que el
sistema gestiona la memoria virtual, incrementar el número máximo de
archivos abiertos de forma simultánea y otros cambios. Los lectores
interesados pueden encontrar información al respecto en la documentación
que acompaña al código fuente del núcleo de Linux.

Todos los mandatos que indicamos a continuación deben ser ejecutados por
el usuario root.


Control del protocolo ICMP

-Ignorar las peticiones de repuesta a ping

Dependiendo de la configuración de la red, puede ser interesante
configurar el sistema para que éste no responda cuando recibe un ping
(mensaje ECHO del protocolo ICMP). De esta forma, puede ser un poco más
difícil que un atacante descubra si el sistema está conectado a la red.

Para desactivar las respuesta de forma temporal:

# sysctl -w net.ipv4.icmp_echo_ignore_all=1

y para desactivarla de forma permanente, editar el archivo
/etc/sysctl.conf y añadir las líneas

net.ipv4.icmp_echo_ignore_all = 1

(Nota= En los siguientes parámetros, si se desea realizar el cambio de
forma permanente deberá modificarse igualmente el archivo
/etc/sysctl.conf, tal como hemos hecho para este parámetro).


-No atender a las peticiones enviadas mediante broadcast

Cuando una máquina envía un paquete a la dirección de broadcast (por
ejemplo, 192.168.1.255), éste es entregado a todas las máquinas
existentes en la red local. A continuación, todas las máquinas deben
enviar un mensaje ECHO del protocolo ICMP. Esto puede provocar una
congestión de la red, a la vez que permite determinar que sistemas están
activos en la red.

Para desactivar la recepción de paquetes enviados a la dirección de
broadcast:

# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts = 1


-Protección ante mensajes de error mal formateados

Es posible que una red se transmitan mensajes de error mal formateados.
Para evitar que éstos sean procesados por el sistema:

# sysctl -w net.ipv4.icmp_ignore_bogus_error_responses = 1


-Deshabilitar la aceptación de redirecciones

Cuando el ordenador utiliza una ruta extinta o no-óptima para enviar un
paquete a un destino particular, los routers por donde circula el
paquete envían al origen un mensaje de redirección del protocolo ICMP
para informar de la ruta correcta a utilizar en el futuro.

Si un atacante tiene la capacidad de enviar mensajes de redirección
puede modificar las tablas de direccionamiento del ordenador, haciendo
por ejemplo que todo el tráfico fluya a través de una vía concreta.

Para evitar el proceso de estos mensajes en el sistema:

# sysctl -w net.ipv4.conf.all.accept_redirects = 0
# sysctl -w net.ipv4.conf.default.accept_redirects = 0


Protección contra ataques DoS de inundación SYN

El ataque de denegación de servicio (DoS) por inundación SYN ("SYN
Flood") consigue consumir todos los recursos de la máquina, haciendo que
sea necesario reiniciarla para volver a funcionar con normalidad.

Cada vez que se realiza una conexión TCP/IP existe una negociación de
tres pasos:

1. El cliente envía un paquete (paquete 1) al servidor con el bit SYN
activado y permanece a la escucha.
2. El servidor responde al cliente con un paquete de confirmación
(paquete 2) y permanece a la escucha.
3. El cliente envía un tercer paquete (paquete 3) que consolida la
conexión.

La información recibida en el paquete 1 se conserva dentro de una cola
para que pueda ser comparada con los datos recibidos en el paquete 3 y
dar por establecida la conexión. Esta cola es de un tamaño limitado y
tiene un tiempo de latencia muy elevado.

El ataque de inundación SYN consiste en llenar esa cola, mediante el
envío de un gran número de paquetes 1 y nunca respondiendo con un
paquete 3. En el momento en que se llena la cola, el sistema es incapaz
de atender cualquier otra petición de conexión que reciba.

La protección contra este ataque consiste en añadir información en el
paquete 2, de forma que no sea necesaria conservar en el servidor ningún
dato sobre el cliente.

Para activar esta protección:

# sysctl -w net.ipv4.tcp_syncookies = 1

Con este valor, el sistema utilizará el método de incluir la información
en el paquete 2 siempre que la cola de paquetes por procesar esté
saturada.


Protección contra direcciones IP no válidas

Esta protección permite que la máquina no pueda utilizarse para el envío
de paquetes con direcciones IP no válidas. Este tipo de paquetes son
habitualmente enviados cuando la máquina está intentando realizar una
acción potencialmente ilegítima, como puede ser la suplantación de una
conexión o el envío de paquetes en un ataque de denegación de servicio.

Para activar esta protección:

# sysctl -w net.ipv4.conf.all.rp_filter = 2
# sysctl -w net.ipv4.conf.default.rp_filter = 2

El valor de los parámetros puede ser 0 (valor por omisión, no realizar
ninguna comprobación), 1 (rechazar únicamente las suplantaciones
evidentes) y 2 (realizar una comprobación exhaustiva). Aconsejamos
seleccionar la opción de comprobación exhaustiva.

Esta opción no debe utilizarse en aquellos sistemas que actúen como
cortafuegos o routers.


Redireccionamiento IP

El redireccionamiento IP es que en un sistema con diversos interfaces
activos, se acepten paquetes en un interfaz con destino al otro. Si la
opción de rediccionamiento está activa, la máquina podrá actuar como un
router para el tráfico entre las redes existentes en cada uno de los
interfaces.

Únicamente aquellos sistemas que actúan como cortafuegos o routers o
bien en circunstancias muy especiales deberían tener esta opción activa.

Para verificar que se encuentra desactivada:

# sysctl -w net.ipv4.ip_forward = 0

Tal como hemos indicado anteriormente, en caso de activar con el valor 1
esta opción, también deberemos modificar el valor de
net.ip4.conf.all.rp_filter y net.ipv4.conf.default.rp_filter.


Control de rutas

Habitualmente un sistema no tiene ningún control sobre la ruta utilizada
por los paquetes en su camino hacia su destino. El protocolo TCP/IP
permite establecer la ruta exacta a seguir. Excepto en circunstancias
muy especiales, este soporte deberá ser desactivado para evitar que un
atacante pueda utilizar un sistema concreto como paso para saltarse las
protecciones establecidas en el tráfico.

Para desactivar esta opción:

# sysctl -w net.ipv4.conf.all.accept_source_route = 0
# sysctl -w net.ipv4.conf.default.accept_source_route = 0


Registro de actividades sospechosas

Un último valor de interés nos permite registrar en los archivos de
actividad del sistema aquellas situaciones potencialmente sospechosas:
intento de envío de paquetes con dirección no válida, paquetes con
cambio de rutas y otras situaciones similares.

Se trata de una serie de situaciones que en un funcionamiento normal de
la red no pueden producirse en ninguna circunstancia. Un ejemplo puede
ser la recepción de un paquete a través de un interfaz Ethernet con
dirección origen igual a 127.0.0.1

Para activar el registro de esta actividad:

# sysctl -w net.ipv4.conf.all.log_martians = 1
# sysctl -w net.ipv4.conf.default.log_martians = 1


Xavier Caballé
xavi@hispasec.com



domingo, 24 de noviembre de 2002

Opciones de seguridad en Linux a través de /proc (I)

Diversos parámetros de seguridad de las máquinas que ejecuten Linux
pueden ser controlados a través del sistema de archivos virtual /proc.

/proc es un pseudo-sistema de archivos, ya que en realidad ni él ni
ninguno de los archivos y directorios contenidos en su interior existen
realmente. /proc nos facilita una interfaz para acceder y, en algunos
casos, modificar, algunas estructuras de datos del núcleo del sistema
operativo.

/proc está disponible en el sistema operativo Linux cuando el núcleo se
ha compilado con la opción CONFIG_PROC_FS=Y. También deberemos
seleccionar la opción CONFIG_SYSCTL=Y para poder modificar el valor de
determinados parámetros, como veremos más adelante. La mayoría de
distribuciones incluyen núcleos compilados con esta opción y, como regla
general, es aconsejable seleccionarla en el momento de recompilar el
núcleo.

El sistema de archivos /proc puede montarse automáticamente en el
momento de iniciar el sistema (si así se indica en el archivo
/etc/fstab). En el caso de que sea necesario montarlo manualmente, debe
utilizarse la siguiente orden:

mount -t proc proc /proc

Es aconsejable que /proc sea montado automáticamente al sistema y que el
núcleo siempre se compile para dar soporte a este pseudo- sistema de
archivos. En caso de no disponer del soporte, muchos programas de
utilidad no funcionarán y no podremos modificar en tiempo de ejecución
algunos parámetros del núcleo del sistema operativo. Muchos de estos
parámetros que nos pueden interesar modificar son muy importantes desde
el punto de vista de seguridad.


Contenido de /proc

Dentro del directorio /proc encontramos dos tipos básicos de
información. En primer lugar, para cada proceso activo existe un
directorio. Dentro del directorio de cada proceso hay diversos archivos
así como un subdirectorio con información específica del proceso
(parámetros pasado en la línea de órdenes, enlace al directorio actual
del proceso, las variables de entorno dentro del contexto del proceso,
los descriptores de los archivos abiertos en el proceso, mapa e
información acerca de la utilización de la memoria...).

Adicionalmente, existen una serie de directorios con información acerca
de los diferentes módulos del sistema operativo. En el archivo proc.txt
(disponible en el directorio Documentation/filesystems del código fuente
del núcleo de Linux) hay información detallada de todo lo que podemos
encontrar dentro de /proc. Otro documento de interés es ip-sysctl.txt,
disponible en el directorio Documentation/networking del código fuente
del núcleo de Linux.

No todos los parámetros existentes en /proc son modificables
directamente por el usuario. De hecho, la mayoría son valores de sólo
lectura y otros son mucho mejor controlados por el núcleo o mediante la
utilización de los diversos mandatos y herramientas existentes en el
sistema.


/proc/sys/net/ipv4

Dentro de este directorio disponemos de una serie de archivos con los
valores y parámetros para el protocolo IPv4. Se trata de los valores
directamente utilizados por el núcleo del sistema operativo en las
comunicaciones TCP/IP basadas en el protocolo IPv4.

Para determinar el valor de uno de estos parámetros lo único que tenemos
que hacer es mirar su contenido. Por ejemplo:

$cat /proc/sys/net/ipv4/icmp_echo_ignore_all
0

nos muestra que actualmente el sistema operativo tiene asignado el valor
0 (desactivado) al parámetro ICMP_ECHO_IGNORE_ALL.

El usuario root del sistema tiene el privilegio de modificar el valor de
estas variables:

# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# cat /proc/sys/net/ipv4/icmp_echo_ignore_all
1

Otra forma de configurar los valores es utilizando la utilidad sysctl.
Utilizando el ejemplo anterior, para determinar el valor debemos
utilizar:

$ sysctl net.ipv4.icmp_echo_ignore_all
net.ipv4.icmp_echo_ignore_all = 0

y para establecer el valor:

# sysctl -w net.ipv4.icmp_echo_ignore_all=1
net.ipv4.icmp_echo_ignore_all = 0

Ambas formas son equivalentes y podemos utilizar aquella con la que nos
encontremos más cómodos.

Una última forma de modificar los valores de los parámetros, de forma
que estos se mantengan incluso después de reiniciar el sistema es a
través del archivo /etc/sysctl.conf. Podemos obtener más detalles del
formato de este archivo ejecutando

man systcl.conf

Si se modifica el archivo /etc/sysctl.conf, los parámetros sólo se
activarán la próxima vez que se reinicie la máquina o bien después de
reiniciar el soporte de red, ejectuando

/etc/rc.d/init.d/network restart



Xavier Caballé
xavi@hispasec.com



sábado, 23 de noviembre de 2002

Actualización para seis nuevas vulnerabilidades en Internet Explorer

Microsoft publica un parche acumulativo que incluye las
funcionalidades de todos los parches publicados anteriormente para
Internet Explorer 5.01, 5.5 y 6.0. Además, esta actualización corrige seis nuevas vulnerabilidades.
Las vulnerabilidades corregidas son las siguientes:

Desbordamiento de búfer producido al comprobar incorrectamente los
parámetros de un gráfico PNG.

Vulnerabilidad de divulgación de información en la forma en que
Internet Explorer trata caracteres codificados en una URL.

Vulnerabilidad al comprobar incorrectamente el componente que realiza
las llamadas a las etiquetas OBJECT. Este problema podrá permitir a un
atacante obtener el nombre del directorio de archivos temporales de
Internet.

Tres vulnerabilidades que aunque difieren en su causa tienen los
mismos efectos. Las tres vulnerabilidades resultan de comprobaciones
de seguridad incompletas que se disparan al emplear determinadas
técnicas de programación web, y pueden tener como efecto el permitir a
un sitio web acceder a información en otro dominio, incluido el
sistema local del usuario.

Microsoft facilita la actualización necesaria para evitar estas
vulnerabilidades en:
http://www.microsoft.com/windows/ie/downloads/critical/q328970/default.asp



Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin MS02-066
Cumulative Patch for Internet Explorer
http://www.microsoft.com/technet/security/bulletin/MS02-066.asp

What You Should Know About Microsoft Security Bulletin MS02-066
http://www.microsoft.com/security/security_bulletins/ms02-066.asp

viernes, 22 de noviembre de 2002

Spam de troyanos

Detectada una nueva ola de envíos masivos de e-mails para distribuir
troyanos. En esta ocasión intentan engañar al usuario simulando ser un
mensaje de su propio servidor de correo que no ha podido ser entregado
y viene devuelto.

Los mensajes tienen como remitente MAIL-DAEMON@[dominio_del_usuario],
asunto "FAILED DELIVERY", el cuerpo es un texto que simula ser un
aviso del servidor de correo que informa que no ha podido entregar un
mensaje, y por último nos encontramos con el archivo adjunto MAIL.HTA.

Como muestra uno de los envíos recibidos en Hispasec:

<---
From: mail-daemon@hispasec.com
To: bernardo_quintero@hispasec.com
Sent: Tuesday, November 19, 2002 7:57 PM
Subject: FAILED DELIVERY

Your message, attached
did not reach the reciepent.
181207@hispasec.com #5.5.0 smtp; 550 Requested action not taken:
mailbox unavailable.
- --->

También se han detectado envíos con el siguiente cuerpo en el mensaje:

<---
Unfortunately, it was not possible to deliver one or more of your
messages. For more information, please, take a look in the attachment.
- --->

En ambos casos se adjunta el archivo MAIL.HTA (HTml Application) que
contiene el troyano. En caso de que el usuario abra dicho fichero se
despliega una ventana con un mensaje HTML falso para despitar,
mientras que de forma oculta al usuario se escribe el troyano en el
disco duro y procede a su ejecución.

El procedimiento es muy simple, MAIL.HTA lleva una sencilla rutina en
VBScript que se encarga de hospedar el volcado del troyano en una
variable, escribirlo en el disco duro del usuario, como
"c:\Progra~1\Outloo~1\outl32.scr" o "c:\sys615.scr", y ejecutarlo.

El troyano volcado es reconocido por algunos antivirus como
"Downloader-BO" o "Inor", y ya ha sido utilizado en otros spams
similares. Su principal función consiste en conectar con una servidor
de Internet y descargar nuevos componentes y troyanos.

Lo más curioso de este incidente ha sido el uso de la Ingeniería
Social, el hecho de hacer pasar el mensaje por un aviso del servidor
de correo del usuario, invitándole a abrir el archivo adjunto.

En cuanto a la ola de spams distribuyendo troyanos, que ya tuvo
una incidencia significativa el pasado 12 de noviembre, una de las
hipótesis que se barajan es que se trate de un intento de hacerse
con el control del máximo número de PCs para posteriormente
utilizarlos de forma coordinada en un ataque masivo tipo DoS.

Desde Hispasec, una vez más, aconsejamos extremar las precauciones
a la hora de abrir archivos adjuntos que lleguen a nuestro buzón,
de forma especial en aquellos casos que no hayamos solicitado su
envío explícitamente. En caso de duda, algo tan simple como pedir
confirmación al remitente puede evitar en ocasiones problemas
mayores.


Bernardo Quintero
bernardo@hispasec.com



jueves, 21 de noviembre de 2002

Parche crítico para millones de Windows

La nueva vulnerabilidad detectada se encuentra en Microsoft Data Access
Components (MDAC) y afecta prácticamente a todos los sistemas Windows,
ya que puede ser explotada tanto en servidores como clientes. La propia
Microsoft reconoce que se trata de una vulnerabilidad crítica, ya que
permite conseguir el control total de los sistemas afectados de forma
remota. De entrada sólo se libra del problema Windows XP, que
distribuye por defecto MDAC 2.7, mientras que todas las versiones
anteriores se encuentran afectadas.

MDAC es un componente que proporciona funciones para acceder a bases
de datos y se distribuye por defecto en Windows XP, Windows 2000 y
Windows Me, además de incluirse en otros productos distribuidos de
forma masiva, como por ejemplo el Option Pack para Windows NT 4.0, o
en el propio navegador de Microsoft, Internet Explorer. En lo que
respecta sólo a servidores webs, la vulnerabilidad afectaría a la
mayoría de los más de 4 millones de servidores de Internet que
utilizan Microsoft Internet Information Server (4.071.863 según la
estadística de octubre de Netcraft). El número de clientes afectados,
usuarios de Windows 95, 98, ME y 2000, sería mucho mayor y difícil
de calcular.

La propia naturaleza de la vulnerabilidad, y el hecho de que afecte
a millones y millones de sistemas, lo convierten en un problema
crítico que, además, podría ser aprovechado para desarrollar gusanos
de alta propagación que infectarían de forma automática, tipo Code
Red o Nimda.

MDAC proporciona la funcionalidad subyacente para un gran número de
opereciones de bases de datos, como la conexión a bases de datos
remotas y devolver datos a los clientes. Uno de los componentes MDAC,
conocido como Remote Data Services (RDS), proporciona la funcionalidad
necesaria para soportar arquitectura en tres capas.

Se ha encontrado una vulnerabilidad en la implementación RDS,
específicamente, en una función llamada RDS Data Stub, cuyo propósito
es analizar las peticiones HTTP entrantes y generar comandos RDS.

La vulnerabilidad proviene de un búfer sin comprobar en el Data Stub.
Mediante el envío de una petición HTTP maliciosa al Data Stub, un
atacante podrá provocar el desbordamiento de búfer e incluso lograr la
ejecución de código mediante el envío de una petición cuidadosamente
construida.

Como ya hemos comentado anteriormente, esta vulnerabilidad se considera
crítica y puede afectar tanto a servidores web como a clientes web. Por
todo esto, desde Hispasec recomendamos encarecidamente la instalación
del parche publicado por Microsoft para paliar este problema y que se
encuentra disponible en:
http://download.microsoft.com/download/dasdk/Patch/Q329414/W98NT42KMe/EN-US/q329414_mdacall_x86.exe


Antonio Ropero
antonior@hispasec.com
Bernardo Quintero
bernardo@hispasec.com


Más información:

Microsoft Security Bulletin MS02-065
Buffer Overrun in Microsoft Data Access Components Could Lead to Code Execution
http://www.microsoft.com/technet/security/bulletin/MS02-065.asp

Remotely Exploitable Buffer Overflow in Microsoft MDAC
http://www.foundstone.com/knowledge/randd-advisories-display.html?id=337

miércoles, 20 de noviembre de 2002

Compromiso remoto de root en iPlanet WebServer

Bajo determinadas circunstancias un atacante puede ejecutar comandos
(generalmente como root), mediante la combinación de dos
vulnerabilidades de seguridad en iPlanet Web Server 4.* hasta SP11.

Estas dos vulnerabilidades son:

- Funciones open() inseguras en scripts PERL de Admin Server
- Cross Site Scripting

La única necesidad será, a través de ingeniería social, lograr que el
administrador revise los logs desde iPlanet Admin Server.

Si se considera cada vulnerabilidad independiente no existe
posibilidad de ejecutar comandos en el iPlanet Web Server. El servidor
sufre una vulnerabilidad de cross site scripting cuando el
administrador revisa los logs de error a través del iPlanet Admin
Server. El exploit reside en emplear la vulnerabilidad en el open() de
PERL a través de la vulnerabilidad de cross site scripting para
redireccionar el navegador del administrador a la URL que provoca la
inyección de comandos a través de open(). Como el administrador ya
está autenticado, evitará la autenticación.


Antonio Ropero
antonior@hispasec.com


Más información:

iPlanet WebServer, remote root compromise
http://www.ngsec.com/docs/advisories/NGSEC-2002-4.txt

martes, 19 de noviembre de 2002

Seguridad de las redes inalámbricas: Wardriving y Warchalking

¿Cuáles son los métodos habitualmente utilizados para identificar la
existencia de una red inalámbrica (wireless network) vulnerable? ¿Cómo
protegernos de los mismos?

Últimamente están proliferando las redes inalámbricas gracias a la
reducción del coste del hardware necesario así como a las ventajas de
poder desplazarse libremente por los edificios manteniendo la conexión
con la red o modificar la disposición de los ordenadores sin necesidad
de hacer obras.


Las redes inalámbricas. Resumen de la topología

Una red inalámbrica tiene dos componentes principales: las estaciones
(STA) y los puntos de acceso (AP). Pueden operar en dos modalidades:
ad-hoc, en la que cada cliente (STA) se comunica directamente con los
otros clientes de la red y en modalidad de infraestructura, donde las
STA envían los paquetes a una estación central, el punto de acceso. Éste
PA actúa como si de un bridge Ethernet se tratara.

El cliente y el punto de acceso deben establecer una relación antes de
poder intercambiar datos. Esta relación puede utilizar tres estados
diferentes:

1. Sin autenticación y disasociado
2. Con autenticación y disasociado
3. Con autenticación y asociado

El intercambio de datos 'reales' sólo es posible en el tercer estado. El
PA transmite tramas con señales de gestión en periodos de tiempo
regulares. Las STA reciben estas tramas e inician la autenticación
mediante el envío de un trama de autenticación. Una vez realizada
satisfactoriamente la autenticación, la STA envía la trama asociada y el
PA responde con otra trama asociada.


Seguridad en las comunicaciones inalámbricas

El estándar 802.1 establece diversos mecanismos para conseguir entornos
de redes seguras. Los mecanismos utilizados habitualmente son:

* Wired Equivalent Protocol (WEP)

Se trata del primer mecanismo implementado y fue diseñado para ofrecer
un cierto grado de privacidad, pero no puede equiparse (como a veces se
hace) con protocolos de redes tales como IPSec. WEP comprime y cifra los
datos que se envían a través de las ondas de radio.

WEP utiliza una clave secreta, utilizada para la encriptación de los
paquetes antes de su retransmisión. El algoritmo utilizado para la
encriptación es RC4.

Por defecto, WEP está deshabilitado.

* WEP2

Es una modificación del protocolo WEP realizada el año 2001, como
consecuencia de una serie de vulnerabilidades que se descubrieron. No
obstante, todavía hoy no existe ninguna implementación completa de WEP2.

* Open System Authentication

Es el mecanismo de autenticación definido por el estándar 802.11 y
consiste en autenticar todas las peticiones que reciben. El principal
problema de este mecanismo es que no realiza ninguna comprobación y,
además, todas las tramas de gestión son enviadas sin ningún tipo de
encriptación, incluso cuando se ha activado WEP.

* Access Control List (ACL)

Si bien no forma parte del estándar, la mayor parte de los productos dan
soporte al mismo. Se utiliza como mecanismo de autenticación la
dirección MAC de cada STA, permitiendo el acceso únicamente a aquellas
estaciones cuya MAC figura en la lista de control de acceso (ACL).

* Closed Network Access Control

Sólo se permite el acceso a la red a aquellos que conozcan el nombre de
la red, o SSID. Éste nombre viene a actuar como contraseña.


Identificación de redes

La identificación de redes es el método para detectar la existencia de
un PA a una red inalámbrica. Para ello, se utiliza una WNIC (tarjeta de
red inalámbrica) funcionando en modo promiscuo conjuntamente con un
software que permite verificar la existencia de puntos de acceso.

En el momento en que se detecta la existencia de una red abierta,
habitualmente se dibuja una marca en el suelo donde se anotan las
características de la misma. Esto se conoce Wardriving y, una vez
realizado, permite disponer de un autentico mapa donde se anotan todos
los puntos de acceso con sus datos (SSID, WEP, direcciones MAC, etc...).


Wardriving

Es el método más conocido para detectar las redes inalámbricas
inseguras. Se realiza habitualmente con un dispositivo móvil, como un
ordenador portátil o un PDA. El método es realmente simple: el atacante
simplemente pasea con el dispositivo móvil y en el momento en que
detecta la existencia de la red, se realiza una análisis de la misma.

Para realizar el Wardriving se necesitan realmente pocos recursos. Los
más habituales son un ordenador portátil con una tarjeta inalámbrica, un
dispositivo GPS para ubicar el PA en un mapa y el software apropiado
(AirSnort para Linux, BSD- AriTools para BSD o NetStumbler para
Windows).


WarChalking. Un nuevo lenguaje

Se trata de un lenguaje de símbolos utilizado para marcar sobre el
terreno la existencia de las redes inalámbricas, de forma que puedan ser
utilizadas por aquellos que 'pasen por allí'. El lenguaje como tal es
realmente simple:

Símbolo Significado

SSID
)( Nodo abierto
Ancho de banda

SSID
() Nodo cerrado

SSID Contacto
( W ) Nodo WEP
Ancho de banda


Por ejemplo, el símbolo

Retina
) (
1.5

identifica a un nodo abierto, que utiliza el SSID "Retina" y dispone de
un ancho de banda de 1.5 Mbps.


Protección de la redes inalámbricas

Existen una serie básica de medidas para la protección de las redes
inalámbricas. Ninguna de ellas, por si sola, impide el acceso no
autorizado a la red por lo que será necesario utilizar una combinación
de, idealmente, todas ellas.

* Filtrado de direcciones MAC

Los puntos de acceso deben tener una relación de las direcciones MAC que
pueden conectarse. No es un método que ofrezca un alto grado de
seguridad, pero es una medida básica para evitar que el primero que pase
por la calle pueda acceder a la red.

* WEP

WEP ofrece un cierto grado de protección por lo que, a pesar que el
mecanismo de cifrado es relativamente simple y la existencia de
programas para determinar cual es la clave de encriptación utilizada,
debe estar siempre activado.

* SSID (identificador de red)

Este identificador es necesario para permitir a las STA comunicarse con
el PA. Puede verse como si se tratara de una contraseña de acceso. El
SSID se transmite en claro por la red, excepto si se ha activado la
encriptación mediante WEP. No obstante, en los diversos dispositivos, el
SSID se almacena sin cifrar, por lo que un atacante con acceso físico a
una STA puede acceder a él.


Consideraciones de diseño

Como paso previo a la aplicación de medidas de protección de una red
inalámbrica, es importante diseñar la red de forma correcta. Algunas
medidas básicas a implementar son:

* Establecer redes privadas virtuales (VPN), a nivel de cortafuegos,
para la encriptación del tráfico de la red inalámbrica.

* No deben conectarse directamente los PA a la red interna 'clásica' de
la empresa. Las redes inalámbricas deben recibir el mismo trato que
cualquier otra red insegura, como puede ser la conexión a Internet. Por
tanto, entre la red inalámbrica y la red 'clásica' deberá existir un
cortafuegos y mecanismos de autenticación.

* Como ampliación del punto anterior, no deben colocarse los PA detrás
del cortafuegos.

* Los clientes de las redes inalámbricas deben acceder a la red
utilizando mecanismos tales como Secure Shell (SSH), redes privadas
virtuales (VPN) o IPSec. Estos mecanismos facilitan los mínimos
necesarios en lo referente a la a autorización, autenticación y
encriptación del tráfico.


Xavier Caballé
xavi@hispasec.com



lunes, 18 de noviembre de 2002

Resumen actualidad CriptoRed

Resumen de las novedades producidas durante el mes de octubre de 2002
en CriptoRed, la Red Temática Iberoamericana de Criptografía y
Seguridad de la Información.

1. Congresos y seminarios con fechas vigentes:

(20-22 noviembre 2002 - USA) Fifth Smart Card Research and Advanced
Application Conference
http://www.usenix.org/events/cardis02/cfp/

(25-29 noviembre 2002 - Cuba) II Congreso Internacional de Telemática
http://www.ispjae.cu/eventos/citel/

(23-26 abril 2003 - Francia) 5th International Conference on
Enterprise Information System
http://www.iceis.org/

(28-31 octubre 2003 - México) Segundo Congreso Iberoamericano de
Seguridad Informática CIBSI '03
http://www.escom.ipn.mx/cibsi/index.html


2. Nuevos artículos y documentos por orden alfabético:

Exámenes de Seguridad Informática (archivo actualizado)
http://www.criptored.upm.es/paginas/docencia.htm#examenes

Aplicaciones de los Autómatas Celulares a los Criptosistemas de
Cifrado en Flujo
http://www.criptored.upm.es/paginas/investigacion.htm#tesis


3. Altas:

Número actual de miembros: 327
http://www.criptored.upm.es/paginas/particulares.htm


4. Otros temas de interés:

Accesos al servidor en octubre: 11.284 ; descargas de archivos: 3.869
http://www.criptored.upm.es/paginas/estadisticas.htm#anyo2002

Clausurada IX Semana Técnica Internacional de Seguridad Informática
(Colombia)
http://www.unab.edu.co/programas/sistemas/seguridad/index.htm

Presentada CriptoRed en diversas universidades de Colombia, Uruguay y
Argentina

Alfred Menezes, René Peralta y Mauro Cansian, conferenciantes
invitados en CIBSI' 03
http://www.cacr.math.uwaterloo.ca/~ajmeneze/
http://cs-www.cs.yale.edu/homes/peralta/
http://www.dcce.ibilce.unesp.br/~adriano/


Jorge Ramió Aguirre
Coordinador General CriptoRed


Más información:


CriptoRed
http://www.criptored.upm.es

domingo, 17 de noviembre de 2002

Desbordamiento de búfer en Oracle iSQL*Plus

Una vulnerabilidad de desbordamiento de búfer en el componente Oracle
iSQL*Plus de Oracle 9 puede llegar a comprometer la integridad del
servidor.

Oracle iSQL*Plus es una aplicación basada en web que permite a los
usuarios lanzar consultas contra una base de datos. Se instala con el
servidor de bases de datos Oracle 9 y corre por encima de apache. El
módulo iSQL*Plus es vulnerable a una vulnerabilidad de desbordamiento
de búfer.

La aplicación web iSQL*Plus requiere que los usuarios se autentifiquen
para acceder. Después de acceder a la url por defecto, "/isqlplus" se
presenta una pantalla de conexión. Mediante el envío de un parámetro
de identificación de usuario excesivamente largo, se produce un
desbordamiento de un búfer interno provocando la sobreescritura de la
dirección de retorno. Esto puede permitir al atacante la ejecución de
código en el contexto de seguridad del servidor web.

Oracle ha publicado parches para evitar este problema que pueden
descargarse desde el sitio Oracle Metalink http://metalink.oracle.com/
con el número de identificación 2581911.


Antonio Ropero
antonior@hispasec.com


Más información:

Oracle iSQL*Plus buffer overflow
http://www.nextgenss.com/advisories/ora-isqlplus.txt

Buffer Overflow in iSQL*Plus (Oracle9i Database Server)
http://otn.oracle.com/deploy/security/pdf/2002alert46rev1.pdf

sábado, 16 de noviembre de 2002

Seis nuevas vulnerabilidades en Mozilla

Durante estos últimos días se han anunciado diversas vulnerabilidades de
seguridad en Mozilla, así como cualquier otro producto basado en el
mismo.

Mozilla es un entorno de código abierto, de gran calidad, nacido a
partir de una iniciativa de Netscape. Su mayor exponente es el propio
Mozilla, el navegador web sobre el que se basa Netscape 6.x así como el
reciente Netscape 7.0. Pero también hay muchos otros productos que se
basan en Mozilla, tales como otros navegadores, entornos de desarrollo,
sistemas de navegación...

Durante los últimos días se han anunciado la existencia de diversas
vulnerabilidades que, básicamente afectan a las versiones de Mozilla
anteriores a la 1.0.1.

* Corrupción de memoria al procesar archivos GIF con el atributo WIDTH
del tag fijado en 0.

Un atacante remoto puede provocar un desbordamiento de buffer cuando en
una página HTML se incluyen diversas marcas con el atributo WIDTH
fijado en 0. Aunque no se ha verificado, es posible que esta
vulnerabilidad permita a un atacante remoto ejecutar código, con los
privilegios del usuario que utiliza Mozilla.

Existe una prueba de concepto de esta vulnerabilidad en
http://crash.ihug.co.nz/~Sneuro/zerogif/

Esta vulnerabilidad está presente en todas las versiones de Mozilla
anteriores a la 1.1, en las diferentes plataformas. También afecta a
Netscape 6.2.x así como al Opera 5.x y 6.x para Linux.

* El evento "onUnload" de JavaScript puede revelar información sobre las
páginas web que se visitan.

Un error en la implementación del evento "onUnload" puede permitir a un
webmaster conocer a que páginas acceden los usuarios en el momento de
abandonar su sede web.

Existe una prueba de concepto de esta vulnerabilidad en
http://members.ping.de/~sven/mozbug/refcook.html

Esta vulnerabilidad afecta a todas las versiones de Mozilla existentes
hasta la fecha, incluyendo a Mozilla 1.1.

* En determinadas circunstancias, cuando se utiliza document.open() como
acción a realizar de un formulario, puede producirse un desbordamiento
de buffer, que provocará la finalización inesperada de Mozilla.

Existe una prueba de concepto de esta vulnerabilidad en
http://bugzilla.mozilla.org/attachment.cgi?id=91590&action=view

Esta vulnerabilidad afecta a las versiones de Mozilla anteriores a la
1.0.1.

* Como consecuencia de un error en la implementación de la función
onkeypress cuando debe procesar la barra espaciadora. Esto puede ser
utilizado para instalar, sin conocimiento ni autorización por parte del
usuario, un paquete XPI.

Esta vulnerabilidad afecta a las versiones de Mozilla anteriores a la
1.0.1.

* En circunstancias concretas, Mozilla no informa correctamente al
usuario del cambio del nivel de seguridad cuando se produce una
redirección desde una página ubicada en un servidor seguro (HTTPS) a un
servidor estándar (HTTP).

Esta vulnerabilidad afecta a todas las versiones de Mozilla anteriores a
la 1.0.1.

* El objeto XMLSerializer, que forma parte del paquete XMLExtras, no
realiza ninguna comprobación del origen de los parámetros, de forma que
un objeto invocada puede acceder a las propiedades de otro dominio
cargado en un frame o iframe separado.

Existe una prueba de concepto de esta vulnerabilidad en
http://www3.sympatico.ca/ndeakin/test/sectest.html

Esta vulnerabilidad afecta a todas las versiones de Mozilla anteriores a
la 1.0.1.


Xavier Caballé
xavi@hispasec.com



viernes, 15 de noviembre de 2002

Vulnerabilidad de denegación de servicio en AIX 4.3.3 y 5.1.0

Existe una vulnerabilidad de denegación de servicio en el sistema
operativo AIX de IBM. Un atacante puede provocar, en determinadas
configuraciones, la detención inesperada del sistema.

En los sistemas AIX 4.3.3 y 5.1.0 con la opción "sack" (Selective
Acknowledgement, reconocimiento selectivo) activa, un atacante que
retransmita una serie de paquetes TCP especialmente formateados, puede
provocar la detención inesperada del sistema vulnerable.

La función "selective acknowledgment", definida en el RFC 2018,
permite la recuperación de paquetes TCP perdidos. Se trata de una
función que mejora de forma apreciable el rendimiento de las
comunicaciones en aquellas redes donde hay una gran cantidad de
pérdidas de paquetes o bien cuando las comunicaciones se realizan a
través de múltiples redes.

La vulnerabilidad descubierta se encuentra en la función
tcp_UpSACKInfo(). Cuando se recibe una gran cantidad de paquetes
retransmitidos en un corto período de tiempo provoca la detención del
sistema. El ataque puede ser realizado de forma remota.

IBM ha publicado sendos APAR para solucionar la vulnerabilidad:
* AIX 4.3.3
http://techsupport.services.ibm.com/support/rs6000.support/fixsearch?fixdb=aix4&srchtype=apar&query=IY30696

* AIX 5.1.0
http://techsupport.services.ibm.com/server/aix.fixdist51?fixes=IY30975&whichFix=APAR

Alternativamente, como solución temporal, puede desactivarse la
función sack ejecutando el siguiente mandato:

usr/sbin/no -o sack=0


Xavier Caballé
xavi@caballe.com



jueves, 14 de noviembre de 2002

Un troyano en tcpdump y libpcap

El servidor utilizado para la distribución de dos utilidades muy
utilizadas por los profesionales de la seguridad, tcpdump y libpcap, fue
atacado el pasado 11 de noviembre. El objetivo: introducir un troyano en
el código fuente de estos programas.

Libpcap es una biblioteca de funciones que implementan funciones para la
captura de paquetes en una red, para lo cual coloca la tarjeta de red en
modo promiscuo. Se trata de una librería utilizada por una gran cantidad
de productos: snort (sistema de detección de intrusos), tcpdump (el
sniffer por excelencia en el mundo *nix), Ksnuffle (sniffer para entorno
KDE), Ethereal (otro popular sniffer, para Unix y Windows) y otros
muchos programas.

Tcpdump, por su parte, es un programa que coloca la tarjeta de red en
modalidad promiscua y captura los paquetes que circulan por la red. Se
trata de una herramienta muy versátil, especialmente utilizada en tareas
de seguridad informática (por ejemplo, en la evaluación de la seguridad
de una red) así como en el análisis del funcionamiento de las redes.

El pasado 11 de noviembre un atacante tomo el control del servidor
tcpdump.org y modificó el código fuente de ambos productos, añadiendo un
troyano.

El troyano consistía en una modificación del archivo de configuración
(./configure) y de uno de los archivos de código fuente en C.

Durante el proceso de configuración, la versión modificada de
./configure descargaba el código fuente de un programa, lo compilaba y
lo ejecutaba. Este programa abre una puerta trasera en el puerto
1964/tcp que permite a un atacante tomar el control del sistema
afectado.

Por otra parte la modificación efectuada en el código fuente de libpcap
es para ignorar todo el tráfico con origen o destino a la puerta
trasera.

Las versiones que incluyen el troyano son las siguientes:

MD5 Sum 73ba7af963aff7c9e23fa1308a793dca libpcap-0.7.1.tar.gz
MD5 Sum 3a1c2dd3471486f9c7df87029bf2f1e9 tcpdump-3.6.2.tar.gz
MD5 Sum 3c410d8434e63fb3931fe77328e4dd88 tcpdump-3.7.1.tar.gz

Aconsejamos verificar que la suma de control MD5 de los archivos
descargados no coincide con estos valores. También puede ser
aconsejable, en caso de duda, descargar las versiones de tcpdump
y libpcap disponibles en

http://sourceforge.net/projects/tcpdump/
http://sourceforge.net/projects/libpcap/

También aconsejamos configurar las herramientas de seguridad
perimetrales, en especial aquellas no basadas en libpcap, para que
verifiquen cualquier tráfico con destino al puerto 1964/tcp.

En estos momentos, el servidor tpcdump.org está fuera de línea. Por
tanto, ambos productos sólo pueden descargarse de sourceforge.net. No
es conveniente utilizar un servidor mirror, ante la posibilidad de que
éstos dispongan de una versión con el troyano.


Xavier Caballé
xavi@hispasec.com



miércoles, 13 de noviembre de 2002

Denegación de servicio en Monkey HTTP Server

Monkey HTTP Server se ve afectado por una vulnerabilidad de denegación
de servicio.
Monkey es un servidor Web escrito en C para trabajar bajo sistemas
Linux. Se trata de un proyecto OpenSource basado en el protocolo HTTP/1.1.

Recientemente se ha dado a conocer la existencia de una vulnerabilidad
de denegación de servicio en Monkey HTTP Server. La vulnerabilidad es
debida a las comprobaciones inadecuadas al decodificar las peticiones
POST. Un atacante podría explotar esta vulnerabilidad al realizar una
petición POST con la cabecera con Content-Length no válido, o sin el
valor Content-Length.

Los productos afectados son:

Monkey, HTTP Daemon, 0.4
Monkey, HTTP Daemon, 0.4.1
Monkey, HTTP Daemon, 0.4.2
Monkey, HTTP Daemon, 0.5

Los parches y correcciones que palian este problema están disponibles en
la dirección:
http://monkeyd.sourceforge.net/down.php?vrs=MC41LjE=


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


Más información:


Bug in Monkey Webserver Causes DoS (POST)
http://www.securiteam.com/unixfocus/6N0052060K.html

martes, 12 de noviembre de 2002

Nuevas vulnerabilidades en BIND4 y BIND8

Una vez más se han descubierto importantes vulnerabilidades en BIND, el
software servidor de nombres de dominio más popular para los diversos
sistemas Unix.

BIND (también conocido como 'named') es el software servidor de nombres
de dominio (DNS) más popular en las diferentes versiones y
distribuciones del mundo Unix. Se trata de un software desarrollado por
ISC (Internet Software Consortium, un consorcio en donde están
representadas algunas de las empresas más importantes del sector
informático) y que se distribuye de forma totalmente gratuita y con el
código fuente completo. Muchos sistemas operativos incluyen de forma
estándar BIND y, en la mayoría de los casos, es instalado en diversas
configuraciones habituales.

BIND es un producto que, a lo largo de los años, ha aumentado en
complejidad. Fruto de ello, existen tres versiones habitualmente
utilizadas (y para cada versión, existen diferentes revisiones): 4.x,
8.x y 9.x. Es importante señalar que las vulnerabilidades más
importantes que se han anunciado afectan únicamente a los usuarios de
las versiones antiguas: 4.x y 8.x.

* Vulnerabilidad: Desbordamiento de buffer en la preparación de
respuestas a registros de recursos (RR)

Afecta a BIND4 (versiones anteriores a la 4.9.10-REL, incluida) y
BIND8 (versiones anteriores al a 8.3.3-REL, incluida) y se trata de un
desbordamiento de buffer que puede ser utilizado por un atacante remoto
para comprometer el servidor vulnerable.

* Vulnerabilidad: Denegación de servicio (DoS) ante una petición de
resolución de un subdominio no existente

BIND 8 (versiones anteriores a la 8.3.3-REL, incluida) finaliza su
ejecución cuando reciben una petición de resolución sobre un subdominio
no existente o bien una solicitud de resolución acerca de un dominio
cuyo servidor autoritativo no es accesible. Si el paquete UDP de
consulta tiene un gran tamaño, el proceso del servidor de nombres aborta
inesperadamente.

* Vulnerabilidad: Denegación de servicio (DoS) provocada por consultas a
objetos que han caducado en la memoria caché.

Afecta a BIND 8 (versiones anteriores a la 8.3.3-REL, incluida). Un
atacante puede hacer que el servidor de nombres almacene en la memoria
caché registros de recursos con un tiempo de caducidad no válido.
Estos registros son borrados de la base de datos interna de NAMED,
pero posteriormente son incorrectamente consultados, lo que provoca la
finalización inesperada del proceso del servidor de nombres.


Como actuar...

En aquellos servidores de nombres en donde no sea necesaria la recursión
(que no deban atender a peticiones de resolución de nombres de dominio
sobre los que no tiene autoridad), se aconseja desactivar la misma.

En BIND4 hay que añadir la opción

options no-recursion

en el archivo /etc/named.boot, mientras que en BIND 8 se debe añadir

options {
recursion no;
};

en el archivo /etc/named.conf

Otra posible solución temporal pasa por filtrar las peticiones dirigidas
al puerto 53/tcp en los servidores de nombres situados en las zonas
perimetrales (DMZ), de forma que sólo se procesen las peticiones
recibidas vía UDP. No obstante, no se ha verificado que esta solución
temporal sea realmente efectiva.

Los usuarios de las versiones 4 y 8 de BIND deberían considerar
seriamente la migración, a la mayor brevedad posible, a la versión
9.2.1. En caso de que esto no sea factible, ISC ha anunciado que
próximamente estarán disponibles actualizaciones para las versiones
vulnerables.

También exista a posibilidad de plantearse la utilización de un software
alternativo a BIND, como puede ser djbdns (http://cr.yp.to/djbdns.html).
Se trata de un producto funcionalmente equivalentes a BIND, pero
diseñado desde el principio con la seguridad como requisito.


Xavier Caballé
xavi@hispasec.com



lunes, 11 de noviembre de 2002

Certificaciones de productos, ¿garantía de seguridad o marketing?

La reciente certificación "Common Criteria" otorgada a Windows 2000
desata la polémica sobre cual es el alcance real de estos galardones
sobre la seguridad final de los usuarios.

Las certificaciones, básicamente, son un procedimiento por el cual una
parte, en principio imparcial, asegura que un producto, proceso o
servicio cumple con una serie de puntos bien definidos. Partiendo de
esta base los beneficiarios de esa certificación serían tanto los
proveedores, como demostración ante terceros del cumplimiento de una
serie de requisitos, así como los clientes, que cuentan con una
evaluación independiente que asegura que no les dan gato por liebre,
una especie de "control de calidad". Hasta aquí todo bien.

Mi visión sobre las certificaciones es bastante más crítica, en parte
formada por los contrasentidos que regularmente me encuentro entre
los galardones que ofrecen la mayoría de certificaciones antivirus y
los resultados que obtenemos en los tests que realizamos a esos mismos
productos durante los análisis y comparativas en Hispasec. Aunque hay
muchos matices a discutir, básicamente podríamos resumir en que la
metodología utilizada y los requisitos que se exigen en las
certificaciones no se ajustan a las necesidades reales de los usuarios
y, por tanto, no aseguran un nivel adecuado de protección.

A partir de aquí para mí desaparece el concepto de "calidad" asociado
a las certificaciones, que pasan a ser simplemente la confirmación
de que un producto, en un determinado momento y bajo unas
circunstancias muy concretas, cumple un determinado número de
requisitos. La certificación no me asegura que los requisitos
evaluados cubran mis necesidades, ni que las circunstancias especiales
en las que se cumplen dichos requisitos se den en mi entorno real, ni
me puede garantizar que el producto en su próxima actualización siga
cumpliendo esos mismos requisitos, y mucho menos puede asegurar (de
hecho es más que probable que ocurra) que dentro de x semanas no se
descubra una nueva vulnerabilidad crítica que ponga en entredicho no
ya al producto, sino incluso a la propia certificación.

En estos momentos todo el mundo recuerda cuando a Windows NT le
otorgaron el nivel de seguridad C2, de acuerdo con los estándares de
seguridad del Departamento de Defensa de Estados Unidos según el
criterio del famoso libro naranja. Entre los "detalles" nos
encontramos que la certificación la obtenía un sistema Windows NT sin
conexión alguna de red, de lo contrario dejaba de ser seguro. ¿Cuántos
sistemas Windows NT se instalan para que funcionen de forma aislada?.
Por lo demás, no vamos a enumerar las vulnerabilidades que se
descubrieron a posteriori y que afectaban de lleno a los requisitos
del nivel C2 (aun estando el sistema sin conexiones de red).

En el caso de la certificación "Common Criteria" recientemente
otorgada a Windows 2000, de la que nos hacíamos eco en la anterior
entrega de "una-al-día", comparto con mi compañero Xavier Caballé
en que se trata de una muestra más del interés que está mostrando
Microsoft por la seguridad y, sobre todo, del interés en explotarla
como herramienta de marketing, que en mi opinión es la auténtica
funcionalidad que tienen las certificaciones para los productos
evaluados.

Con esto no quiero criticar a Microsoft, realmente pienso que está
consiguiendo adelantos en materia de seguridad en sus productos.
Para llegar a esta conclusión, más que fijarme, o fiarme, de los
anuncios de galardones, prefiero observar detalles más mundanos que
nos afectan a diario a todos como, por ejemplo, que su nueva política
de distribuir actualizaciones acumulativas está disminuyendo los
riesgos de sufrir regresiones en las vulnerabilidades así como la
omisión de parches específicos.

En definitiva, la obtención de certificaciones por parte de productos
es un indicador positivo, si bien no garantizan su seguridad global
ni la adecuación a nuestro entorno y necesidades reales. La seguridad
es un proceso constante que no debe ser medido puntualmente y de
forma aislada.


Bernardo Quintero
bernardo@hispasec.com



Más información:

09/11/2002 - Microsoft obtiene una credencial de mérito
http://www.hispasec.com/unaaldia.asp?id=1476

24/07/2002 - Certificaciones antivirus obsoletas
http://www.hispasec.com/unaaldia.asp?id=1368

domingo, 10 de noviembre de 2002

Seguridad y teletrabajo

Cada vez más, las empresas favorecen el teletrabajo. ¿Qué implicaciones
tiene esto para la seguridad?

La mayoría de trabajos que realizan los profesionales de la informática
(o computación, como se denomina en los países latinoamericanos) han
sido siempre tareas muy propensas a ser desarrolladas de forma remota
por el trabajador, sin que éste deba desplazarse a la oficina. No
obstante, las limitaciones tecnológicas siempre han dificultado este
tipo de trabajo. Actualmente la situación está cambiando. La difusión de
las conexiones a Internet con un ancho de banda aceptable, hace que cada
vez más empresas y trabajadores se planteen la posibilidad de
desarrollar su actividad profesional (o parte de ella) de forma remota.

Abrir la red corporativas a trabajadores remotos, que acceden (o no) a
través de Internet es realmente una decisión muy importante y que debe
ser meticulosamente analizada antes de realizarse. Existen otras
alternativas, tales como la utilización de los servicios de terminal
(mediante Citrix o Terminal Server en el mundo Windows) que, en la
mayoría de las situaciones, son mucho más recomendables.

Si se opta por abrir el acceso a la red corporativa a los usuarios
remotos, es preciso adoptar diversas medidas, tanto para proteger la red
corporativa como para proteger el ordenador del teletrabajador.

Hay un factor muy importante a tener en cuenta: si el teletrabajador
tiene acceso a la red corporativa y su ordenador es controlado por un
atacante, automáticamente el atacante puede tener acceso a la red
corporativa.

Un reciente estudio realizado por SonicWALL en Estados Unidos muestra
que el 83% de las empresas ya disponen de cómo mínimo un trabajador que
realiza parte de su trabajo desde su domicilio. Más revelador es otro
dato revelado por este mismo estudio: un 43% de los teletrabajadores
acceden a la red corporativa desde su domicilio, habitualmente a través
de Internet.

Lo preocupante del informe es la poca importancia que se da a las
medidas de seguridad. Así si las tres cuartas partes de las empresas
estudiadas realizan una revisión de quién está autorizado a acceder de
forma remota, únicamente una tercera parte de las empresas analiza quien
puede tener acceso al ordenador en la casa, además del teletrabajador.

Entre las medidas de seguridad adoptadas en los ordenadores de los
teletrabajadores, una mayoría significativa la basa en la utilización de
antivirus (81%) y cortafuegos personales (71%). Otras medidas de
protección son menos habituales: 44% utilizan software para el filtrado
del contenido y menos de una tercera parte utiliza redes privadas
virtuales.


7 líneas de protección

Cualquier trabajador que acceda de forma remota a los recursos
corporativos a través de Internet debería disponer de, como mínimo, de
estas siete líneas de protección:

1. Traducción de direcciones de red (NAT)

La red interna del trabajador debe utilizar un rango de direcciones
privadas. De esta forma, las direcciones internas de la red no pueden
ser utilizadas en Internet sin que previamente hayan sido convertidas.

2. Cortafuegos/router para la conexión ADSL o cable

La mayoría de los routers existentes para las conexiones ADSL y de cable
permiten aplicar reglas de filtro de paquetes. Por tanto es necesario
aprovechar esta prestación para realizar un filtrado del tráfico de
salida y entrada.

3. Un cortafuegos con inspección de estado

Los cortafuegos con inspección de estado no se limitan a analizar que el
tráfico está formateado de una forma correcta (dirección IP de origen y
destino válida, las marcas correctas, protocolo permitido, etc...) sino
que van más allá y comprueban que el contenido del paquete sea realmente
aquello que se espera.

Es muy aconsejable utilizar un sistema de cortafuegos con inspección de
estado como una medida adicional de protección al cortafuego de filtrado
de paquetes. Una máquina Linux con Netfilter es un excelente cortafuegos
con inspección de estado.

4. Utilizar cortafuegos personales en cada sistema

Los cortafuegos personales son una combinación de cortafuegos de
filtrado de paquetes y de inspección de estado que se ejecutan en el
ordenador. Básicamente lo que hacen es analizar el tráfico de la red,
monitorizando y restringiendo los intentos de conexión. Algunos
cortafuegos personales incluyen, además, funciones propias de sistemas
de detección de intrusos.

Una de las características más interesantes es que nos informan de que
aplicaciones están accediendo a recursos remotos. ¿No es extraño que el
NOTEPAD.EXE -bloc de notas-intente conectar con una dirección IP de
Rusia?

Conocer este tipo de actividad de la red puede ser vital para descubrir
cualquier incidencia en el ordenador.

5. Verificación automática de puertos abiertos

De forma periódica debe realizarse una verificación de los puertos
abiertos en la conexión, tanto a nivel del router ADSL/cable periférico
como en el propio ordenador.

La existencia de puertos abiertos puede indicar la instalación de
software que actúa como servidor o la presencia de troyanos.

6. Software antivirus

No únicamente debe considerarse el antivirus como un sistema de
detección de virus informáticos. Muchos troyanos son también detectados.
De hecho, en muchas ocasiones la primera alarma ante el ataque de un
ordenador viene dada por el propio antivirus.

Debe configurarse el software antivirus para que realice la
actualización del archivo de firmas de forma automática, como mínimo una
vez a la semana.

7. Verificación de vulnerabilidades

De forma periódica las estaciones de trabajo de los teletrabajadores
deben ser verificadas con un sistema de verificación de vulnerabilidades
con el objeto de descubrir cual es su nivel de protección ante las
diversas vulnerabilidades existentes. Una vez descubiertas estas, deben
tomarse las medidas adecuadas para eliminarlas.


Otras medidas adicionales de protección pueden ser el encapsulamiento
del tráfico con destino a la red corporativa a través de una red privada
virtual (VPN), donde pueden aplicarse la encriptación del tráfico. No
obstante, una VPN puede ser totalmente inútil si previamente no se han
aplicado las otras medidas de protección básicas.


Xavier Caballé
xavi@hispasec.com



sábado, 9 de noviembre de 2002

Microsoft obtiene una credencial de mérito

Aunque a primera vista pueda costar de creer, el gigante de Redmond
acaba de obtener un prestigioso reconocimiento relacionado con la
seguridad.

El pasado 29 de octubre Microsoft anunció que la línea de sistemas
operativos Windows 2000 (versiones Professional, Server y Advanced
Server) han obtenido la certificación "Common Criteria". Se trata de un
estándar aprobado por la ISO (ISO- IEC 15408) establecido para la
evaluación de las funciones de seguridad y las prestaciones de los
productos tecnológicos. Actualmente está certificación es reconocida por
14 países (Australia, Nueva Zelanda, Canadá, Francia, Alemania, Reino
Unido, Estados Unidos, Finlandia, Grecia, Italia, Israel, Holanda,
Noruega y España) y que se considera como una de las máximas
certificaciones que pueden obtenerse en lo relativo a la seguridad
informática.

¿Significa este paso que Microsoft se está tomando en serio todo lo
relacionado con la seguridad informática? Con el riesgo de verme atacado
por todos los detractores de Microsoft, mi impresión es que sí.

Para obtener la certificación, Microsoft ha tenido que asumir la
realización de auditorías de seguridad del código fuente, exhaustivas y
costosas. Y si alguna cosa no se le puede negar a Microsoft es que
últimamente está invirtiendo muchos recursos, tecnológicos, financieros
y humanos a los diferentes aspectos de la seguridad. En total, Microsoft
ha sido un ejercicio de tres años de duración, desarrollado por cientos
de ingenieros, con un coste de varios millones de dólares.

Dicho esto, la obtención del "Common Criteria" es únicamente un punto de
partida para aumentar el nivel de seguridad. Como si fuera un mal
presagio, sólo un día después del anuncio de la obtención de esta
certificación, Microsoft anunció la existencia de tres nuevas
vulnerabilidades, una de ellas considerada como crítica. Una de estas
vulnerabilidades afectaba a un sistema de seguridad evaluado durante el
proceso de obtención de la certificación.

Versiones certificadas

La certificación se ha expedido para Windows 2000 Professional, Windows
2000 Server y Windows 2000 Advanced Server con el Service Pack 3 y el
hotfix Q326886 instalado (este hotfix elimina un problema en el gestor
de conexiones de red que puede ser utilizado por un atacante para
aumentar sus privilegios en el sistema).

La certificación ha consistido en el análisis de diversos componentes
del sistema operativo: módulo criptográfico, directorio activo, sistema
de archivos y los sistemas de control de acceso. También se han
analizado los otros componentes del sistema que tienen alguna relevancia
desde el punto de vista de la seguridad.

También debe tenerse en cuenta que las configuraciones presentadas por
Microsoft no son configuraciones especialmente diseñadas para aumentar
la seguridad a costas de las funcionalidades. Se trata de
configuraciones estándar, en las que únicamente se han modificado
algunos parámetros de seguridad de acuerdo con las guías de seguridad de
Microsoft.


Xavier Caballé
xavi@hispasec.com



viernes, 8 de noviembre de 2002

Se resuelve un reto de criptografía de curvas elípticas

Tras cuatro años, un equipo de la universidad de Notre Dame, en Indiana,
ha superado el reto ECCp-109, propuesto por la empresa Certicom en 1997.

La criptografía de curvas elípticas permite la creación de
criptosistemas asimétricos (como RSA), pero utilizando curvas elípticas
en vez de números primos. Su ventaja fundamental consiste en que las
claves son mucho más cortas (160 bits en vez de 1024 bits, por ejemplo)
y los requerimientos de memoria y CPU para realizar las operaciones
criptográficas son bastante inferiores. Su desventaja fundamental es que
muchas de sus variantes están patentadas y no pueden utilizarse de forma
libre.

El reto ECCp-109 fue propuesto por Certicom (empresa que posee numerosas
patentes sobre esta tecnología) en 1.997, ofreciendo un premio de 10.000
dólares a quien consiguiese descifrar un mensaje cifrado con una clave
ECC de 109 bits.

El equipo de la universidad de Notre Dame mantuvo 10.000 ordenadores
funcionando 24 horas durante 549 días para obtener descifrar el mensaje.
El descifrado en sí se realizó mediante fuerza bruta, no "rompiendo" el
algoritmo o la tecnología.

El reto ECCp-109, desde 1997, ha atraído a más de 247 equipos de todo el
mundo, sumando más de 10.308 personas. Certicom patrocina estos retos
como una forma de verificar la seguridad de su tecnología, para aumentar
el conocimiento de la misma por parte del público y para demostrar la
robusted del sistema criptográfico incluso con claves de pequeño tamaño.

Comercialmente Certicom utiliza tecnología de 163 bits, lo que resulta
unos cien millones de veces más robusta que el reto resuelto.

El equipo ganador donará 8.000 de los 10.000 dólares ganados a la FSF
(Free Software Foundation), promotora de la licencia GNU GPL (usada,por
ejemplo, en Linux e infinidad de proyectos "Open Source").

El próximo reto Certicom es el ECCp-131, valorado en 20.000 dólares.


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


Más información:

Notre Dame Math Whiz Cracks Certicom Code Contest
http://ca.news.yahoo.com/021106/5/q31n.html

Weak Elliptic Curve Cryptography Brute-Forced
http://slashdot.org/article.pl?sid=02/11/06/2154224&mode=thread&tid=93

Certicom Announces Elliptic Curve Cryptosystem (ECC) Challenge Winner
http://www.certicom.com/about/pr/02/021106_ecc_winner.html

Welcome to the Certicom ECC Challenge
http://www.certicom.com/resources/ecc_chall/challenge.html
http://www.certicom.com/resources/ecc_chall/download.html

Certicom offers crypto contest
http://news.com.com/2100-1023-205254.html?tag=bplst

Certicom
http://www.certicom.com/

Elliptic curve cryptography FAQ v1.12 22nd December 1997
http://www.cryptoman.com/elliptic.htm

jueves, 7 de noviembre de 2002

Aprobación de SAML como estándar OASIS

OASIS (Organization for the Advancement of Structured Information
Standards, organización para el avance de estándares de información
estructurada) aprueba la publicación del estándar SAML, lo que abre
innumerables posibilidades de interoperatividad entre sistemas de
seguridad de diferentes fabricantes.

SAML (Security Assertion Markup Language, lenguaje de marcas para
"aserciones" -condiciones- de seguridad) es un estándar XML que
permitirá el intercambio de autorizaciones y autentificaciones entre
entidades no relacionadas. El proyecto "Single Sign-On" de Liberty
Alliance está basado en SAML, por ejemplo.

Con el advenimiento de tecnologías como SOAP, XML-RPC y "Web Services",
SAML proporciona un idioma común para el despliegue de toda la
infraestructura de seguridad.

Entre los promotores de OASIS se cuentan IBM, Hewlett-Packard, BEA
Systems, Sun Microsystems, VeriSign, Computer Associates, Netegrity, RSA
Security, Baltimore Technologies, Entrust, Oblix, OpenNetwork, Hitachi o
Quadrasis.

La documentación SAML está disponible online, de forma gratuita.


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


Más información:

Security Assertion Markup Language (SAML) Ratified as OASIS Open
Standard. Authentication and Authorization Standard Enables Single
Sign-On for Web Services
http://www.oasis-open.org/news/oasis_news_11_06_02.shtml

Oasis Gives SAML 1.0 a Thumbs-Up
http://slashdot.org/article.pl?sid=02/11/06/2356242&mode=thread&tid=95

SAML 1.0 specification gets a thumbs-up
http://ww1.infoworld.com/cgi-bin/fixup.pl?story=http://www.infoworld.com/articles/hn/xml/02/11/06/021106hnsaml.xml&dctag=webserv

OASIS
http://www.oasis-open.org/

Security Assertion Markup Language (SAML)
http://xml.coverpages.org/saml.html

miércoles, 6 de noviembre de 2002

Dos problemas de denegación de servicio en Oracle9iAS Web Cache

Se han detectado dos problemas de denegación de servicio en Oracle Web
Cache, uno de los componentes la suite Oracle Application Server.

Oracle Web Cache es una parte de la suite Oracle Application Server.
El Web Cache server está diseñado para ser implementado delante de Oracle
Web server y actuar como cache de servidor de proxy inverso.

Existen dos ataques diferentes de denegación de servicio, que podrá
provocar la caída del servicio Web Cache. Las condiciones de
denegación de servicio pueden explotarse mediante simples peticiones
HTTP al servicio Web Cache.

La primera de las denegaciones de servicio se produce al efectuar una
petición HTTP GET que contenga al menos un punto-punto-barra en la
URI:

GET /../ HTTP/1.0
Host: whatever
[CRLF]
[CRLF]

La segunda de las denegaciones se produce al efectuar una petición GET
mal construida:

GET / HTTP/1.0
Host: whatever
Transfer-Encoding: chunked
[CRLF]
[CRLF]

Oracle no va a publicar ningún parche para evitar este problema.

Se recomienda emplear técnicas de firewall para restringir el acceso
al puerto de administración de Web Cache.
Usar la característica "Secure Subnets" de la herramienta Web Cache
Manager para proporcionar acceso únicamente a los administradores
desde una lista de direcciones IP o subredes permitidas.


Antonio Ropero
antonior@hispasec.com


Más información:

Oracle9iAS Web Cache Denial of Service
http://www.atstake.com/research/advisories/2002/a102802-1.txt

Oracle9i Application Server - Web Cache Administration Tool Crash on
Malformed Request
http://otn.oracle.com/deploy/security/pdf/2002alert43rev1.pdf

martes, 5 de noviembre de 2002

Cuantificación de las vulnerabilidades en los diferentes sistemas operativos

Un análisis de las vulnerabilidades de seguridad publicadas y los
ataques registrado durante el año 2002 revela cuales son los sistemas
operativos con más vulnerabilidades y que reciben más ataques.

La empresa británica mi2g ha recogido las diferentes alertas de
seguridad publicadas hasta finales de octubre del presente año y ha
analizado el impacto de las mismas en los diversos sistemas operativos.
Este trabajo se reúne dentro de la base de datos SIPS (Security
Intelligence Products and Systems) donde, actualmente, hay datos de más
de 101.000 ataques informáticos y 6.100 grupos de hackers.

Analizando los incidentes en función de los diversos sistemas operativos
se descubre que las diferentes versiones de Windows están afectadas por
un 44% de las vulnerabilidades, seguido de Linux (19%), las diferentes
variantes de BSD (9%) y Solaris 7%. En comparación, únicamente un 0,5%
de las vulnerabilidades anunciadas durante los diez primeros meses del
presente año afectan a SCO Unix y un 1,9% de las mismas afectaban a Mac
OS y a Tru64 de Compaq.

Esta empresa también ha analizado un total de 57.977 ataques contra
sistemas informáticos realizados durante el mismo periodo de tiempo. Así
el sistema operativo más atacado han sido las diferentes versiones de
Windows, con 31.431 ataques (54% del total), seguido nuevamente por
Linux con 17.218 ataques (30%), BSD (6%) y Solaris (5%).

Los otros sistemas operativos tienen un volumen de incidentes registrado
casi despreciable: sólo 31 ataques registrados contra sistemas
ejecutando Mac OS (un 0,05%). Los otros sistemas operativos situados en
la parte inferior de esta escala son SCO Unix con 165 ataques (0,2%) y
Tru64 de Compaq con 10 ataques (0,02%).

Otros sistemas operativos se ven beneficiados de lo que se conoce como
"security by obscurity" y que podría traducirse como "seguridad gracias
al desconocimiento". Entre estos sistemas tenemos a IRIX de SGI que si
bien está afectado por un 6% de las vulnerabilidades sólo ha registrados
dos ataques. Otro caso es AIX de IBM, afectado por un 4% de las
vulnerabilidades y que únicamente ha sido atacado en 199 incidentes.

Tanto número me marea... ¿Qué significa esto?

Básicamente nada. Este informe debe considerarse, básicamente, como una
curiosidad. En los incidentes de seguridad posiblemente más importante
que su número es el efecto que éstos tienen. Un sistema puede recibir
muchos ataques, pero con un impacto reducido o nulo... mientras que otro
puede recibir únicamente un ataque con efectos desastrosos.

Leyendo la nota de prensa uno puede llegar a la falsa conclusión que los
ordenadores con sistema operativo Mac son inmunes a los incidentes de
seguridad informática. Esto debe puntualizarse mucho y una consideración
de este tipo es demasiado categórica como para realizarla tan
banalmente.

Como ya hemos informado en diversos boletines, las vulnerabilidades
también existen en el Mac OS (incluida la versión X) y algunas de ellas
son relativamente importantes. Por otra parte el bajo número de
incidentes registrados es debido, en gran parte, al reducido número de
máquinas con Mac OS X que actúan como servidor, si lo comparamos con el
resto de entornos. Recordemos que Apple presentó sus primeros servidores
con Mac OS X a principios de julio.

¿Y la seguridad por desconocimiento?

Este es otro tipo de protección que, por si sólo, se revela totalmente
insuficiente. El simple hecho de que no anunciemos la existencia de un
sistema no significa que éste no sea descubierto... y a las pruebas
reveladas por el proyecto Honyenet me remito.

No hay por que publicitar datos innecesarios sobre las máquinas
existentes, pero nunca debe considerarse esta ausencia de información
como *LA* medida de protección.



Xavier Caballé
xavi@hispasec.com



lunes, 4 de noviembre de 2002

Fortaleza de las contraseñas

Las contraseñas continúan siendo, todavía hoy, el principal mecanismo
para el control de acceso. ¿Conocemos la fortaleza de las contraseñas
que utilizamos?

NoneLas contraseñas, de un tipo u otro, se han convertido en un elemento
cotidiano de nuestras vidas. Las utilizamos en la alarma de nuestro
domicilio, para sacar dinero del cajero automático, para acceder a la
red, en la conexión a Internet y en el acceso a nuestro correo
electrónico... y así en una infinidad de acciones de nuestra vida
cotidiana. Todavía en la actualidad la protección mediante contraseña
continua siendo la principal (y en muchas ocasiones, la única) medida
para el control de acceso a servicios.

Cuando utilizamos la expresión "fortaleza de la contraseña" estamos
expresando cual es la dificultad que ofrece ésta ante alguien (o algo)
que está intentando descubrirla. Una contraseña será más fuerte cuando
ofrezca mayores dificultades para que el atacante la identifique. Por el
contrario, será más débil cuando sea relativamente simple descubrirla.

Una buena forma de demostrar la necesidad de utilizar contraseñas
fuertes es mostrar la facilidad con que las contraseñas débiles pueden
ser identificadas. La mayoría de los usuarios no tienen ni idea de la
existencia de herramientas para descubrir contraseñas, ni de lo
realmente fáciles y eficientes que son (y en muchos casos, incluso
totalmente gratuitas). Es realmente un ejercicio muy aleccionador
obtener una copia de la SAM de un dominio de Windows, pasarla por una
herramienta de análisis y ver como, instantáneamente, obtenemos la
contraseña de una gran cantidad de usuarios.

Pongamos como ejemplo a LC4 (antiguamente conocido como L0pthcrack). En
primer lugar realiza estas verificaciones: ¿está la contraseña en
blanco? ¿Es igual al identificador del usuario? ¿Es una palabra que se
encuentra en el diccionario o una secuencia fácilmente identificable?

Estas tres simples pruebas se revelan como un buen mecanismo para
identificar, de forma instantánea, las contraseñas más débiles. A
continuación, intenta determinar las contraseñas aplicando la fuerza
bruta: probar todas las combinaciones posibles de caracteres.

Este último método puede requerir un determinado tiempo para identificar
las contraseñas. Desde minutos a días o semanas. Todas las contraseñas
son susceptibles de ser identificadas. Otra cosa es cuántos recursos y
tiempo son necesarios para que sea revelada.

Los resultados que genera LC4 pueden ser difícilmente interpretables. En
este aspecto, me permito recomendar la utilidad L0stat que genera unos
excelentes informes sobre la calidad de las contraseñas analizadas por
LC4.

Evidentemente el problema de la calidad de las contraseñas no es
exclusivo de Windows, sino que puede aplicarse a cualquier entorno en
donde se utilice este tipo de autenticación. En el mundo Unix (y
derivados) la principal herramienta para el análisis de las contraseñas
es "John the Ripper".


Mejorar la calidad de las contraseñas

La política de seguridad existente en cada organización debe fijar los
requerimientos para que una contraseña se considere aceptable dentro del
ámbito de la misma. No obstante, me permito sugerir una serie de valores
que son comúnmente aplicados:

* Todas las cuentas de usuario, sin excepción, deben de tener
asociada una
contraseña.
* El usuario, en su primera conexión a la red, debe ser forzado a
cambiar
de contraseña.
* La longitud de las contraseñas no debe ser inferior a los siete
caracteres.
* Las contraseñas deben estar formadas por una mezcla de caracteres
alfabéticos (donde se combinen las mayúsculas y las minúsculas) y
números.
* La contraseña no debe contener el identificador o el nombre del
usuario.
* Las contraseñas deben caducar, como máximo, cada noventa días. El
período mínimo de validez de una contraseña debe ser un día.
* Cuando se realice un cambio de contraseña, esta debe ser diferente
de
las utilizadas anteriormente por el mismo usuario.
* Periódicamente debe realizarse una auditoría para verificar que se
cumple con los requerimientos de la política de seguridad.


Un recordatorio final...

Nunca, repito, NUNCA debe utilizarse un programa de identificación de
contraseñas, incluso contra los sistemas en los que se dispone de
privilegio de administración, sin la autorización explícita y por
escrito de la empresa propietaria del ordenador. Más de un administrador
de sistemas, actuando con la más benevolente de sus intenciones, ha sido
despedido sencillamente por haber utilizado uno de estos programas sin
la correspondiente autorización.


Xavier Caballé
Xavi@hispasec.com