martes, 31 de diciembre de 2002

Problemas de denegación de servicio en diversos productos Cisco

Algunos productos Cisco que contienen soporte SSH, se ven afectados por
un problema que pueden hacerlos vulnerables a un ataque por denegación
de servicios.

Productos Cisco IOS (Internetwork Operating System),que contienen
soporte SSH, y que lo tienen habilitado pueden verse afectados por una
vulnerabilidad que los hace susceptibles de verse afectados por ataques
por denegación de servicio. Esto ocurriría cuando un atacante enviara
paquetes especialmente mal construidos. El servidor atacado recobrará
su funcionalidad normal tras pasados algunos minutos del ataque, si
bien no se evita que el servidor pueda verse afectado nuevamente por
otro ataque de denegación de servicio.

Los productos de Cisco que contiene la funcionalidad SSH server y que en
estos momentos se han confirmado que no son vulnerables, son:

Cisco Catalyst Switches running Cisco CatOS
Cisco VPN3000 series concentrators
Cisco PIX Firewall
Cisco Secure Intrusion Detection System (NetRanger) appliance
Cisco Secure Intrusion Detection System Catalyst Module
Cisco SN5400 Series Storage Routers
CiscoWorks 1105 Wireless LAN Solution Engine (WLSE)
CiscoWorks 1105 Hosting Solution Engine (WLSE)


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


Más información:

Cisco Vulnerable to SSH Malformed Packet Vulnerabilities
http://www.securiteam.com/securitynews/6M00R1P6AE.html

lunes, 30 de diciembre de 2002

Actualizaciones de Microsoft, un arma de doble filo

A principios de 2002 se presentaba en España, bajo el nombre de
Strategic Technology Protection Program (STPP), la iniciativa de
Microsoft para mejorar la seguridad de sus productos. Tras la
experiencia acumulada en estos últimos meses podríamos resumirla
en una sola palabra: automatización.

Bajo el título de "Microsoft STPP, ¿estrategia tecnológica o lavado
de cara?", intenté por aquel entonces balancear entre los pros y
los contras de la iniciativa, con un pequeño listado de problemas
por resolver que Microsoft arrastraba y que entendía eran críticos
(http://www.hispasec.com/unaaldia.asp?id=1213).

En la situación actual, tras casi un año de STPP, parte de esos
problemas se han minimizado, otros se agravan, y surgen nuevas
interrogantes.


El usuario final mejora su seguridad

Queda claro que Microsoft ha puesto especial empeño en facilitar la
vida a los usuarios automatizando todo el proceso de actualizaciones,
tanto en el ámbito de notificaciones, descarga e instalación. Parece
que nos dirige hacía sistemas totalmente autosuficientes y
transparentes, que se encargarán por nosotros de estar actualizados
puntualmente.

Este planteamiento, que ya se intuía con servicios como Windows
Update y que se hacen más evidentes en sistemas como Windows XP,
corrige en gran parte los problemas de regresión de vulnerabilidades
de antaño, al menos los inducidos directamente por el usuario.
Básicamente, estos problemas aparecían por la instalación de parches
específicos sin el orden adecuado, lo que llevaba a sobrescribir
bibliotecas y componentes con versiones más antiguas y, por tanto, la
aparición de vulnerabilidades anteriores. Con los nuevos servicios de
actualización automática, como Windows Update, es el propio sistema
el que decide que parches y en que orden deben ser instalados,
minimizando este riesgo.

Por contra, esta misma automatización, agrava el enmascaramiento
de nuevas versiones y funcionalidades con la excusa de la seguridad,
lo que en algunos casos ha supuesto la aparición de nuevas
vulnerabilidades. Lo ideal es que cada vulnerabilidad cuente con un
parche específico diseñado para corregirla. Sin embargo, Microsoft
suele ofrecer como solución la actualización a nuevas versiones del
software o componente afectado, algunas veces de forma pública, y
otras veces ocultando las nuevas funcionalidades o modificaciones
en un parche de seguridad.

Las implicaciones de esta política en el ámbito de seguridad son
varias, por un lado las nuevas funcionalidades incorporadas en los
parches o nuevas versiones son en muchos casos origen de nuevas
vulnerabilidades, problemas que no habrían aparecido en los
componentes anteriores si se hubieran limitado a corregir la
vulnerabilidad. Por otro lado, esta práctica es la que provoca la
mayoría de incompatibilidades o mal funcionamiento del sistema con
el hardware / software ya existente tras haber realizado una
actualización de seguridad.

En líneas generales, en lo que respecta al usuario final y balanceando
lo dicho anteriormente, la iniciativa STPP representa un avance
significativo, ya que ha mejorado los tiempos de actualización de los
PCS y facilita en gran manera la tarea al usuario.


Pérdida de control por parte de los administradores y profesionales

Sin embargo, desde el punto de vista de los administradores de
sistemas y profesionales, tanta automatización y abstracción se
traducen en un menor control, que ya de por sí era bastante
limitado en plataformas Microsoft.

De entrada, tanta actualización automática seguro que pone en alerta
a más de un administrador de sistemas, que ya habrá experimentado
como un simple parche a demanda, o el Service Pack de turno, ha podido
volver inestable ciertos servicios, cuando no a todo un servidor. Con
esta experiencia, no es de extrañar que algunas políticas corporativas
contemplen tests de los parches en equipos de pruebas, durante al
menos un mes, antes de pasarlos a los sistemas de producción.

Con STPP se plantean nuevos problemas, ya que Microsoft está optando
en muchas ocasiones por "macro parches" acumulativos, que resuelven
múltiples vulnerabilidades con una sola actualización. Mientras antes
un administrador de sistemas podía decidir si instalar un parche
específico o retrasarlo, dependiendo de sí afectaba a la configuración
de su servidor o si podía prevenirlo por su cuenta (por ejemplo con
reglas en el firewall o modificando la configuración del sistema),
ahora esa opción es muy limitada, por lo que tendremos que instalar
los "macro parches" aun a sabiendas de que algunas correcciones no las
necesitaba nuestro sistema, con las implicaciones que ello pueda
acarrear en cuanto a estabilidad.

Por otro lado, la tendencia parece que apunta a que cada vez más los
sistemas de Microsoft realizarán operaciones y actualizaciones
automáticas, transparentes al usuario, dependiendo de conexiones
externas vía Internet. Algunas de estas tendencias ya pueden verse en
los sistemas de actualización automáticos actuales o en Windows XP,
sin entrar en otras consideraciones como pueden ser el control que
Microsoft puede establecer a través de estas vías, políticas de
control de licencias o fidelización (sólo permitir actualizar a los
usuarios suscritos) y sus implicaciones en el ámbito de la privacidad.
Si extrapolamos esto a un servidor, los administradores de sistemas
tendrán aun menos control o, dicho de otra forma, contarán con un
"superusuario" por encima de ellos: Microsoft.


Windows NT, crónica de una muerte anunciada

Ante este panorama algunos podrían decidir no migrar hacia los nuevos
sistemas de Microsoft y quedarse con plataformas como por ejemplo
Windows NT, sistemas con años en producción, bien conocidos por los
administradores, con múltiples Service Packs a sus espaldas que han
ido puliendo sus defectos y mejorándolo, que ya se encuentran bien
implantados, cumplen su cometido y no necesitan de las nuevas
funcionalidades que propone Microsoft.

Desgraciadamente Windows NT tiene sus días contados, y eso es fácil
de predecir, bien observando la historia reciente de Microsoft, bien
dejándose llevar por simples reglas de mercado: hay que vender los
nuevos productos. En este apartado la seguridad juega un papel
crítico, incluso como herramienta para forzar a la actualización.
Igual que no hay solución para ciertos problemas de seguridad en
Windows 95 o en Internet Explorer 5.0, obligando al usuario a
actualizar a Windows 98 o IE6.0 si quiere estar seguro. Es sólo
cuestión de tiempo que Microsoft deje de dar soporte a Windows NT.


Posibles mejoras

Desde el punto de vista del administrador de sistemas lo ideal sería
ofrecerles la posibilidad de obtener un mayor control. Aunque las
comparaciones en este ámbito son casi inevitables, evitaré entrar
en el eterno debate entre la comunidad Open Source y Microsoft,
no en vano algunas posturas que se podrían copiar y adoptar pueden
sonar a pura quimera. Así que las peticiones serán escasas y simples.

De entrada sería importante que Microsoft, además de los macro
parches acumulativos, ofreciera la posibilidad de obtener parches
específicos e individuales, de forma que el administrador pudiera
optar por una instalación personalizada de los mismos, según
configuración y necesidades.

Llegados a este punto es vital que se ofrezca información más al
detalle sobre las vulnerabilidades, entrando más en profundidad
en la explotación y opciones de mitigación del ataque, así como
en los parches propuestos (que componentes serán actualizados,
que dependencias crea dicha actualización, si se introducen
modificaciones adicionales, etc.).

Bienvenida sería la opción de desactivar todas las dependencias y
conexiones externas y automáticas, tanto a nivel de servidores como
de estaciones de trabajo. Así como documentar el proceso de
WindowsUpdate y facilitar su personalización, posibilitando a los
administradores establecer sus propias políticas y sistemas internos
de autoactualización según necesidades. Aunque Microsoft ya dispone
de soluciones propietarias para la distribución de parches, su
adopción sólo optimiza recursos y cambia el problema de sitio, pero
no permite corregir la situación de dependencia y falta de control.


Bernardo Quintero
bernardo@hispasec.com



domingo, 29 de diciembre de 2002

Publicación del número 60 de "Phrack"

Acaba de publicarse el número 60 del conocido E-Zine "Phrack".

"Phrack", que cuenta ya con más de 16 años de historia, se centra en los
campos de "exploits" y nuevas tecnologías de "hacking", fundamentalmente
en entornos informáticos.

En este último número podemos encontrar artículos sobre:

* Anuncio de nuevas herramientas y utilidades
* Estudio de la pila del kernel
* Cisco IOS exploits
* Parche de kernel estático
* Protección contra vulnerabilidades de desbordamiento de entero
* Información sobre desbordamientos de entero
* Análisis de SMB/CIFS
* Detección de firewalls y análisis de red mediante CRC rotos.
* Diseño de un dispositivo de bajo costo para inhabilitar temporalmente el uso de GPS
* Análisis sobre las luces de tráfico

y otros temas menores.

De lectura recomendable para conocer el "estado del arte" en el mundo
"Underground".


Antonio Ropero
antonior@hispasec.com


Más información:

Phrack
http://www.phrack.org/

sábado, 28 de diciembre de 2002

2002, el año del spam

Neal Stephenson, autor de "Criptonomicón", indica en su página web que,
al igual que Donald Knuth y Umberto Eco, se siente feliz en poder decir
que no dispone de una dirección de correo electrónico. El resto de los
mortales, aquellos que sí deseamos utilizar el correo electrónico, nos
vemos inundados a diario por ingentes cantidades de basura en forma de
bytes.

Me imagino que para la mayoría de los lectores de "Una-al-día" no
causará ninguna sorpresa destacar el enorme porcentaje que representa el
spam, el correo basura, en sus buzones de correo.

Las estadísticas sobre el spam producen auténticos escalofríos. En julio
del presente año, MessageLabs afirmaba que el 36% del correo electrónico
en circulación era correo basura. Por su parte, Júpiter Research,
calcula que el número de mensajes de spam que se envían actualmente se
sitúa en 140.000 millones. Lo más preocupante es que, para el 2007, se
prevé alcanzar una cifra de 650.000 millones de mensajes de correo
basura.

Con estas cifras, es evidente que encontramos una solución que aleje el
spam de nuestros buzones o correremos el riesgo de convertir el correo
electrónico en algo totalmente inutilizable.

Spam, un auténtico problema de seguridad

Hasta la fecha, el spam ha sido básicamente un incordio. Pero durante
este año 2002 hemos visto algunas muestras de cómo el correo basura
también se puede convertir en un problema de seguridad. Como ya hemos
relatado en diversos boletines de "una-al-día", no son pocos los casos
en que mensajes de spam donde se utilizan técnicas de ingeniería social,
han conseguido que los usuarios faciliten información sensible.

Pero hay más. Existen mensajes de spam auténticamente diabólicos,
especialmente para los usuarios de Microsoft Outlook (no por el hecho de
que tenga más problemas que otros programas, sino por el hecho de ser el
programa más utilizado). Mensajes con páginas HTML y scripts capaces de
bajarse código y dejarlo en la máquina del usuario.

Todo esto convertirá el spam, en los próximos meses, como el principal
problema de seguridad en Internet. Los virus que circulan en la
actualidad básicamente sólo tienen el efecto de bloquear los servidores
de correo ante el gran volumen de mensajes infectados que son capaces de
generar. El spam tiene este mismo efecto, sólo que el volumen actual del
correo basura es muy superior al de mensajes infectados por virus.

Detección del spam

Existen diversos métodos para la detección de mensajes con correo
basura. El que ha demostrado un mayor porcentaje de acierto, generando
un reducido (o incluso nulo) número de falsos positivos, son los filtros
basadas en lógica bayesiana a partir del trabajo de Paul Graham.

La lógica bayesiana que se aplica consiste en determinar palabras que
aparecen con frecuencia en los mensajes de spam y, a partir de las
mismas, determinar por el contexto otros términos que se incluyen
habitualmente en el correo basura así como aquellos contextos que
aparece en los mensajes legítimos. El análisis se realiza íntegramente
sobre el contenido del mensaje, dejando de banda el remitente o las
máquinas por las que ha pasado.

El resultado, según Paul Graham, es una detección del 99,5% de los
mensajes de correo basura, con un porcentaje de falsos positivos
prácticamente nulo.

Existen diversos programas que ya implementan los filtros de lógica
bayesiana para la detección del correo basura. A nivel de servidor
podemos indicar SpamProbe y Bogofilter; a nivel cliente de correo, la
última versión de Mozilla (1.3). Es de esperar que en los próximos meses
otros programas, incluyendo los sistemas antivirus actuales, vayan
incorporando estas técnicas para reducir el volumen de spam en
circulación.


Xavier Caballé
xavi@hispasec.com


Más información:

2002: The Year of Spam
http://www.silicon.com/public/door?6004REQEVENT=&REQINT1=56535&REQSTR1=silicon.com

Top-10 Spam List: Still gullible
http://news.zdnet.co.uk/story/0,,t269-s2126973,00.html

Report Confirms Massive Increases in Viruses, Spam
http://www.esecurityplanet.com/trends/article/0,,10751_1556361,00.html

Tech Pros Gather Antispam Forces
http://www.wired.com/news/infostructure/0,1377,56809,00.html

Origin of the term "spam" to mean net abuse
http://www.templetons.com/brad/spamterm.html

A Plan for Spam
http://www.paulgraham.com/spam.html

Inteligencia artificial para luchar contra el correo basura
http://ww2.grn.es/merce/2002/IAantispam.html

SpamProbe - Bayesian spam detector
http://sourceforge.net/projects/spamprobe/

Bogofilter
http://bogofilter.sourceforge.net/

Bogofilter mata major
http://bulmalug.net/body.phtml?nIdNoticia=1537

Junk Mail Classification Turned On in Trunk Builds
http://mozillazine.org/talkback.html?article=2667

Mozilla Spam Filtering
http://www.mozilla.org/mailnews/spam.html

Sólo con leyes no se atajará el "spam", advierten los expertos
http://ww2.grn.es/merce/2002/listasnegras.html

La LSSI no se suavizará en torno al spam
http://barrapunto.com/article.pl?sid=02/12/27/1756253

¿Se puede luchar contra el spamming sin LSSI?
http://barrapunto.com/article.pl?sid=02/11/15/0638243

Spam Volume Statistics
http://www.caube.org.au/spamstats.html

Spam hits 36 percent of e-mail traffic
http://zdnet.com.com/2100-1106-955842.html

645.000 millions de spams no desitjats el 2007
http://nosaltres.vilaweb.com/info/vilaweb/cerca_u.noticia?p_idint=100000568785

Razor. Spam should not be propagated beyond necessity
http://razor.sourceforge.net/

Junk Spy ZAPs spam
http://www.junkspy.com/

Una-al-día (15-05-02): "Spam" para robar datos sensibles
http://www.hispasec.com/unaaldia.asp?id=1298

Una-al-día (29-11-01): El parlamento europeo debate el uso de "cookies" y "spam"
http://www.hispasec.com/unaaldia.asp?id=1131

EuroCAUCE, The European Coalition Against Unsolicited Commercial Email
http://www.euro.cauce.org/en/index.html


viernes, 27 de diciembre de 2002

Tres nuevas vulnerabilidades en Oracle 9i Application Server

Se ha anunciado la existencia de tres vulnerabilidades en Oracle9i Application Server por las cuales un atacante podría llegar a tomar el control del servidor de aplicaciones.
La primera de las vulnerabilidades permite a un atacante la obtención del código fuente de las páginas JSP (Java Server Pages). El segundo de los problemas reside en las instalaciones por defecto de Oracle9i Application Server al permitir a todos los usuarios el control total de todos los archivos del servidor de aplicaciones. Por último bajo determinadas circunstancias, los contenidos de la carpeta WEB-INF queda accesibles para los atacantes lo que permite a los usuarios remotos acceder al código fuente de las aplicaciones e incluso a otra información sensible.

Se recomienda la actualización a la versión Oracle9i Application Server 9.0.2.0.1 para NT y a la versión 9.0.3 para Solaris y otras plataformas UNIX, en las que se encuentran corregidos estos problemas.


Antonio Ropero
antonior@hispasec.com


Más información:

Oracle Security Alert #47
Security Vulnerabilities in Oracle 9i Application Server
http://otn.oracle.com/deploy/security/pdf/2002alert47rev1.pdf

jueves, 26 de diciembre de 2002

Bautizar un virus

"I-Worm.Tanatos", "W32/Bugbear-A" o "NATOSTA.A" , son algunos de los
distintos nombres con los que se puede identificar al mismo virus en
función de que antivirus se utilice. No se trata de un caso aislado,
sino de una constante que en ocasiones crea más de una confusión, y
ya no hablamos de las decenas de versiones y variantes que nos
podemos encontrar como terminación de cada nombre.

Aunque en principio parezca que el nombre que se le de a un virus
determinado carece de importancia, la realidad es que las distintas
nomenclaturas utilizadas por las casas antivirus pueden llegar en
situaciones a confundir a los usuarios, por no contar los quebraderos
de cabeza que supone enfrentarse a la tarea de tratar reportes
de diferentes motores antivirus para sacar una estadística homogénea.

Si bien ya vemos que cada cual bautiza según le viene, la realidad es
que la mayoría de las casas antivirus suelen seguir las reglas de
nomenclatura acordadas por CARO (Computer Antivirus Research
Organization) que diseñaron Alan Solomon, Fridirik Skularson y
Vesselin Bontchev en 1991, actualizadas posteriormente por Gerald
Scheidl en 1999. En conferencias posteriores se ha continuado
discutiendo sobre las reglas, simplificación, adecuación a los nuevos
especímenes, y homogeneización de los nombres de los virus.

La situación actual, con diferencias entre las diferentes casas
antivirus, suele seguir el patrón Prefijo.Nombre.Variante.

El prefijo nos dará información sobre la plataforma y el tipo,
así sabremos si se trata de un virus, un gusano o un troyano, a
que sistemas afecta, o en que lenguaje está escrito. Algunos ejemplos
de prefijos utilizados hoy día son:

WM -> Virus de macro para Word
XM -> Virus de macro para Excel
W32 -> Virus Win32
I-Worm -> Gusano de Internet
Troj -> Caballo de Troya
VBS -> escrito en Visual Basic Script

Mención aparte merecen algunos prefijos que nos indican especímenes
que engordan las cifras de los antivirus pero que realmente no son
virus funcionales, como:

Joke -> Broma (no tiene ningún efecto dañino ni se propaga)
Intented -> Virus que no funciona

Aun así, es preferible los antivirus que utilizan estos prefijos,
para aclarar que no se trata de programas dañinos, en lugar de
aquellos otros que no realizan ninguna diferenciación y pueden
crear más confusión entre los usuarios.

A continuación nos encontraremos con el nombre específico del
virus, que es sin duda la parte que más confusión crea ya que
es la más "creativa". Normalmente guarda relación con algún
nombre o comentario que el propio autor del virus ha dejado
en el interior del código, o bien con el tema utilizado por el
virus como reclamo para presentarse ante los usuarios, el nombre
del archivo con el que se propaga, etc.

La variante dependerá en gran medida del motor antivirus, por lo
que las diferencias pueden ser aun mayores entre las distintas
casas. Así, mientras un motor puede necesitar 8 firmas diferentes
con sus respectivas versiones, otro motor puede llevar a cabo una
detección más genérica de todas las variantes con una sola firma
y bajo un único nombre.

Por último, algunas casas utilizan un sufijo que guarda relación con
el método y velocidad de propagación, así:

@M -> Se propaga a través del correo electrónico
@MM -> Se propaga por e-mail de forma masiva

Tomando únicamente como referencia el nombre del espécimen más
incisivo de toda la historia hasta la fecha, W32/Klez.h@MM, podemos
deducir que:

W32 -> Win32, podrá afectar a Windows 9x/Me/NT/2000/XP
Klez -> Nombre del virus. En el interior de su código encontramos
el comentario:
Win32 Klez V2.01 & Win32 Foroux V1.0
Copyright 2002,made in Asia
h -> Al menos existen 7 versiones anteriores
@MM -> Se distribuye de forma masiva por e-mail


Bernardo Quintero
bernardo@hispasec.com


Más información:

New Virus Naming Convention 1991 (NVNC91)
http://craiu.pcnet.ro/papers/nvnc1991.zip

Virus Naming Convention 1999 (VNC99)
http://members.chello.at/erikajo/vnc99b2.txt

06/09/2002 - Activación y versiones del gusano Klez
http://www.hispasec.com/unaaldia.asp?id=1412

miércoles, 25 de diciembre de 2002

Cambios en la zona raíz del DNS

Tras más de 5 años sin cambios, se publica una actualización de la zona
raíz del sistema DNS.

La zona raíz del DNS es el conjunto de servidores que conforman la raíz
del árbol de DNS. Se usan como punto de partida para realizar la
resolución de nombres DNS, tal y como se describió en un boletín
reciente, en el que se detallaban los ataques de denegación de servicio
que habían padecido esas máquinas.

La zona raíz del DNS no suele cambiar, ya que no se requiere su
corrección absoluta para mantener el sistema en funcionamiento. Los
servidores de DNS la utilizan como punto de arranque al ser lanzados y
tener la caché de resolución vacía, y uno de los primeros pasos que
suele hacer un servidor de DNS es intentar conectarse a alguno de los
servidores raíz para descargarse una versión actualizada.

Dicha versión es usada como versión de trabajo, pero no se suplanta la
versión inicial configurada en el servidor, por lo que la actualización
se pierde al rearrancar el servicio. No obstante, mientras alguno de los
servidores en la versión original siga funcionando, el servidor DNS
puede obtener la versión de trabajo actualizada.

Resulta conveniente, no obstante, actualizar la zona raíz por defecto,
para hacer frente a cualquier eventualidad que pudiera surgir, como la
partición coyuntural de Internet. Esta actualización no es crítica, y se
puede realizar a lo largo de meses.

Para realizar la actualización, se puede utilizar un comando UNIX como:



dig @e.root-servers.net . ns > root.hints



Ese comando se descarga el listado de la zona "." (la zona "raíz) y lo
almacena en el fichero "root.hints". El administrador de cada máquina
debe indicar el fichero correcto en cada caso, no llamándose
necesariamente "root.hints".

Una de las motivaciones de este cambio es poder publicar una misma IP a
través de varias rutas distintas, reflejando máquinas diferentes. Es
decir, cuando un usuario intenta conectarse a una IP determinada, que
está publicada en varios lugares diferentes, llegará a la localización
topológicamente más cercana. En otras palabras, la misma IP puede enviar
a servidores distintos según el continente o el país desde el que se
haga la petición.

De hecho en Hispasec nos consta que, desde hace apenas horas, existe un
servidor de DNS raíz en el nodo neutro de interconexión español,
Espanix. Dicho servidor comparte IPs con otros servidores DNS que se
están instalando por todo el planeta. Gracias a la publicación de rutas
alternativas, los usuarios acceden, de forma transparente, al que les
resulta topológicamente más cercano, y sin conflictos entre las
diferentes máquinas que tienen la misma IP.


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


Más información:

Important Informational Message - root.zone change
http://www.cctec.com/maillists/nanog/current/msg00757.html

Re: Important Informational Message - root.zone change
http://www.cctec.com/maillists/nanog/current/msg00761.html

Root Zone Changed
http://slashdot.org/article.pl?sid=02/11/07/1613256&mode=thread&tid=95

Key internet server relocated
http://www.newscientist.com/news/news.jsp?id=ns99993026

28/10/2002 - Preguntas y respuestas sobre los ataques a los servidores
raíz del DNS
http://www.hispasec.com/unaaldia.asp?id=1464

Fichero de zona raíz DNS.
ftp://ftp.internic.net/domain/named.root

martes, 24 de diciembre de 2002

Vulnerabilidad en Fetchmail

Las versiones no actualizadas de fetchmail contienen un desbordamiento
de búfer que permite la ejecución de código arbitrario, con los
privilegios del usuario bajo el que se ejecuta el proceso.

Fetchmail es una utilidad de los sistema UNIX, que permite a un cliente
la descarga de correo electrónico de los servidores a través de multitud
de protocolos de correo, como POP2, POP3 o IMAP.

Las versiones de fetchmail previas e incluida a la 6.1.3 contienen un
desbordamiento de búfer que permite que un atacante remoto mate el
proceso o consiga ejecutar código arbitrario en la máquina, con los
privilegios del usuario bajo el que se ejecuta fetchmail. El atacante
tan solo necesita enviar a la víctima un mensaje con las cabeceras
formateadas apropiadamente.

La vulnerabilidad reside en una optimización de fetchmail, que intenta
reutilizar memoria dinámica a medida que va procesando las cabeceras,
para mejorar el rendimiento. Lamentablemente dicha gestión es
incorrecta, y permite sobreescribir memoria reservada vía "malloc()" lo
que puede ocasionar la caída del servicio o la ejecución de código
arbitrario, según el sistema operativo, las librerías que se usen y la
suerte (y malicia) del atacante.

La recomendación es que todos los usuarios de fetchmail se actualicen
cuanto antes a la versión 6.2.0, ya disponible.


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


Más información:

The fetchmail Home Page
http://tuxedo.org/~esr/fetchmail/

Advisory 05/2002
Fetchmail remote vulnerability
http://security.e-matters.de/advisories/052002.html

Fetchmail Remote Vulnerability (Localhost @)
http://www.securiteam.com/unixfocus/6Q00F1F6AE.html

Fetchmail remote heap overflow
http://www.securitybugware.org/Linux/5877.html

lunes, 23 de diciembre de 2002

La NSA publica una actualización de su distribución Linux

La NSA acaba de hacer pública una actualización de sus distribución
"segura" de Linux, basado en un kernel Linux 2.4.18.

SELinux es una distribución de Linux realizada por la NSA para cubrir
las necesidades de un sistema operativo que cumpla los criterios
"Trusted" y disponible en código fuente, y poder así hacer frente a la
eventualidad de que desapareciesen los sistemas actualmente en uso, como
Trusted Solaris (Sun), Trusted AIX (IBM) o Trusted IRIX (SGI, antigua
Silicon Graphics).

Desde que se publicó la primera versión, en Diciembre de 2000, se han
ido descubriendo algunos problemas, y las actualizaciones han sido
constantes, tanto para solucionar bugs como para actualizar componentes.
Los usuarios de la versión Linux de la NSA deben actualizar su
distribución de forma periódica, preferiblemente de manera frecuente.

La última versión de SELinux se publicó el 12 de Diciembre de 2002, y
está basada en un kernel Linux 2.4.18, que es la última versión
disponible de la serie estable 2.4.*. La licencia de SELinux es GPL.


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


Más información:

Security-Enhanced Linux
http://www.nsa.gov/selinux/

16/07/2002 - La NSA publica una actualización de su distribución Linux
http://www.hispasec.com/unaaldia.asp?id=1360

23/09/2001 - La NSA distribye una nueva revisión de su distribución
"segura" SELinux
http://www.hispasec.com/unaaldia.asp?id=1064

04/02/2001 - Actualización de la versión Linux de la NSA
http://www.hispasec.com/unaaldia.asp?id=833

28/12/2000 - La NSA publica una versión "segura" de Linux
http://www.hispasec.com/unaaldia.asp?id=795

domingo, 22 de diciembre de 2002

Múltiples desbordamientos de búfer en Winamp

Se anunciado la existencia de vulnerabilidades de desbordamiento de
búfer en diferentes versiones de Winamp, el conocido reproductor de
archivos de sonido.

Se presenta una vulnerabilidad en Winamp 2.81 (la ultima versión 2.x) y
otras dos en Winamp 3.0. El desbordamiento en Winamp 2.81 tiene relación
con el tratamiento de la etiqueta ID3v2 Artist de forma inmediata tras
la carga del MP3. Por su parte los desbordamientos en Winamp 3.0 se
encuentran en el tratamiento de las etiquetas ID3v2 Artist y Album en la
libraría de medios (Media Library).

Un atacante podría crear un fichero MP3 e introducir en dichas etiquetas
unas cadenas muy largas para provocar el desbordamiento de buffer en el
caso de que intentara ser reproducido por una versión de Winamp
vulnerable. El problema podrá permitir al atacante lograr la ejecución
de código en los sistemas afectados.

Nullsoft ha publicado versiones corregidas de Winamp 2.81 y Winamp 3.0
disponibles en: http://www.winamp.com


Antonio Ropero
antonior@hispasec.com


Más información:

Multiple Exploitable Buffer Overflows in Winamp
http://www.foundstone.com/knowledge/randd-advisories-display.html?id=338

Security Fixes For Winamp: Get The Latest And Be Protected
http://www.winamp.com/news.jhtml?articleid=9680

sábado, 21 de diciembre de 2002

Un banco online en casa, con errores de programación

Se presenta WebMaven, un proyecto de código abierto, pensado para ayudar
en la formación y validación de los sistemas de verificación de la
seguridad de las aplicaciones web.

Se presenta WebMaven, un proyecto de código abierto, pensado para ayudar
en la formación y validación de los sistemas de verificación de la
seguridad de las aplicaciones web.

En el desarrollo de aplicaciones web siempre debe existir una fase en la
que se realice una serie de verificaciones para comprobar que no se ha
introducido ningún agujero en la seguridad.

Por lo general, este tipo de pruebas son desarrolladas por empresas de
consultoría o los propios departamentos de seguridad informática. Si
bien existen diversas metodologías para la realización de las pruebas,
siempre queda la duda de estas son capaces de descubrir todos los
errores. Es aquí donde entra WebMaven: ofrecer un entorno de pruebas
que nos permita verificar la calidad de la verificación de la seguridad.

WebMaven v1.01 es una aplicación web interactiva que simula algunos de
los problemas de seguridad más habituales a nivel de aplicación. Esto
lo convierte en un entorno ideal para la revisión de las pruebas de
verificación de la seguridad, así como para comprobar si las técnicas
de valoración se realizan adecuadamente.

La versión actual de WebMaven incluye una aplicación de banca por
Internet, aunque está previsto que en futuras versiones se incluyan
otras aplicaciones de ejemplo.

La arquitectura de WebMaven es relativamente simple: un script escrito
PERL que se ejecuta en un servidor web. Los usuarios interactúan contra
la aplicación web de la misma forma en que lo hacen contra cualquier
otra aplicación web. Por tanto, se pueden utilizar las mismas
herramientas de verificación de la seguridad que se emplean para
comprobar la seguridad de las aplicaciones web.

En la aplicación de ejemplo, Buggy Bank, existe la posibilidad de
establecer sesiones autenticadas de usuario, obtener el estado de las
cuentas corrientes y realizar transferencias. Deliberadamente el sistema
tiene un total de diez vulnerabilidades simuladas, que deberemos ser
capaces de identificar.


Xavier Caballé
xavi@hispasec.com



viernes, 20 de diciembre de 2002

Desbordamiento de búfer en el escritorio de Windows

Un desbordamiento de búfer en el escritorio de Windows puede ser
utilizado para ejecutar código arbitrario en las máquinas que ejecuten
el sistema operativo Microsoft Windows XP.

Windows Shell (lo que todos nosotros denominados el escritorio de
Windows) es el componente de Windows encargado de ofrecer las
prestaciones básicas de interfaz de usuario, tales como la exploración
de archivos y carpetas, configuración del sistema operativo...

Una de las características de Windows Shell, en la versión incluida en
Windows XP, es la posibilidad de extraer automáticamente información de
los archivos de sonido. Esta extracción se realiza cuando el usuario
abre una carpeta que contiene archivos de música (en formato .MP3 o
.WMA) o bien coloca el puntero del ratón encima de uno de estos
archivos. La información extraída (artista, nombre del disco, año..)
aparece en los detalles del archivo.

Se ha descubierto la existencia de un desbordamiento de búfer en dicha
función. Este desbordamiento puede ser utilizado por un atacante para
ejecutar código arbitrario en los sistemas vulnerables, con los
privilegios del usuario que acceda al archivo de música malicioso o
visualice la carpeta.

Es importante señalar que el problema no requiere la presencia física
del archivo MP3/WMA en el disco duro del usuario. Un atacante puede
colocar el archivo especialmente formateado en una página web o mensaje
en formato HTML (o bien en un recurso compartido de la red) y cada vez
que un usuario coloque el puntero del ratón encima del icono, podrá
provocar la ejecución del código asociado.

Este problema afecta a todas las versiones de Windows XP disponibles
actualmente: Windows XP Home, Windows XP Professional, Windows XP Tablet
PC y Windows XP Media Center.

Microsoft ha publicado la actualización necesaria para eliminar esta
vulnerabilidad que puede instalarse mediante el servicio Windows Update
(http://windowsupdate.microsoft.com) o bien instalando directamente el
parche:

Windows XP (edición 32-bit)
http://microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=A0BE7AF2-2653-4767-A85D-24BF68D28D20

Windows XP (edición 64-bit)
http://microsoft.com/downloads/details.aspx?FamilyId=FBA972FB-FF2A-41D0-8745-D31EEFB90437&displaylang=en


Xavier Caballé
xavi@hispasec.com



jueves, 19 de diciembre de 2002

Se distribuye de forma abierta un documento sobre la seguridad de MULTICS

El documento describe un estudio de seguridad realizado a mediados de
los años 70, en el que se demuestra cómo saltarse los mecanismos de
protección de MULTICS, de forma casi trivial.

MULTICS es un sistema operativo desarrollado a finales de los años 60,
con un claro objetivo: ser seguro. Lamentablemente su diseño estaba muy
vinculado a una determinada familia de CPUs (General Electric, luego
Honeywey), era poco portable y consiguió poca difusión. Podría decirse
que su mayor contribución a la historia de la informática ha sido,
precisamente, su fracaso: Su complejidad y dependencia de un hardware
específico motivó, por un puro movimiento de reacción, el nacimiento de
"UNIX" (nombre puesto en evidente alusión a su clara divergencia de
"MULTICS"). UNIX hereda, no obstante, un buen número de diseños de
MULTICS, como el que "todo" sea un fichero.

Durante décadas, la mitología informática atribuía a MULTICS habilidades
y una seguridad inaudita, avaladas por su utilización en las redes
informáticas de las fuerzas armadas norteamericanas. Esta percepción
queda absolutamente demolida con el documento que presentamos hoy, en el
que se describe un estudio "superficial" (bajo coste) sobre la seguridad
de MULTICS.

El estudio describe un sinfín de ataques, tanto software (bugs y
problemas de diseño en el sistema operativo) como hardware (bugs en la
implementación de las CPUs, implementaciones incompletas y efectos
colaterales inesperados). La mayoría de los ataques fueron explotados de
forma simple y exitosa. Algunas de las puertas traseras desplegadas
permanecieron activas durante meses.

Algunas de las conclusiones finales son demoledoras: (traducción libre)

..."Desafortunadamente, los productos de los grandes vendedores [de
software y hardware] ignoran, en su mayor parte, estos riesgos probados.
En su defensa, la mayoría de los vendedores podrían decir que el mercado
no está preparado para pagar por una mayor seguridad"..

..."En nuestra opinión se trata de un estado transitorio inestable.
Resulta impensable que transcurran treinta años sin que ocurra una de
estas dos cosas: o ocurrirán terribles desastres informáticos que priven
a la sociedad de buena parte de la utilidad que los ordenadores pueden
proporcionar, o existirá tecnología lo bastante madura como para que los
productos informáticos sean verdaderamente seguros. Sinceramente
esperamos que sea lo segundo".

Desde HispaSec se nos hace evidente que esos treinta años han
transcurrido sin que esas palabras hayan perdido ni un ápice de
actualidad...


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


Más información:

Documento original
http://csrc.nist.gov/publications/history/karg74.pdf

Classic Computer Vulnerability Analysis Revisited
http://slashdot.org/article.pl?sid=02/09/09/179246&mode=thread&tid=172

Multics
http://www.multicians.org/

miércoles, 18 de diciembre de 2002

Actualización de seguridad de MySQL

Se han descubierto varias vulnerabilidades en MySQL, tanto en el
servidor en sí como en las librerías clientes.

MySQL es un servidor de bases de datos SQL, "open source", de altas
prestaciones, extremadamente difundido en el mundo Linux.

Las dos vulnerabilidades del servidor permiten matar el proceso, y una
de ellas, bajo circunstancias propicias, posibilita ejecutar código
arbitrario con los privilegios del usuario que ejecuta MySQL,
típicamente "mysqld".

En las librerías clientes, se puede provocar la caída del proceso o la
escritura de un cero ("\0") en cualquier dirección de memoria del mismo.

Detalles:

* Desbordamiento entero en "COM_TABLE_DUMP". Requiere que el atacante
tenga acceso a la base de datos. Permite DoS (ataque de denegación de
servicio).

* Vulnerabilidad en la gestión de "COM_CHANGE_USER". Requiere que el
atacante tenga acceso a la base de datos. Puede permitir le ejecución de
comandos arbitrarios en el servidor.

* Desbordamiento de búfer en la función "read_rows" de la librería
cliente MySQL. Permite DoS.

* Mala gestión en "read_one_row". Un puntero ilegal permite escribir un
"\0" en cualquier lugar de de la memoria del proceso cliente.

La recomendación es actualizar a la versión 3.23.54 de MySQL, ya
disponible.


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


Más información:

Advisory 04/2002
Multiple MySQL vulnerabilities
http://security.e-matters.de/advisories/042002.html

MySQL Overflow and Authentication Bugs May Let Remote Users Execute Code
or Access Database Accounts
http://www.securitytracker.com/alerts/2002/Dec/1005800.html

MySQL
http://www.mysql.com/

martes, 17 de diciembre de 2002

Múltiples vulnerabilidades en diversas implementaciones de SSH

Se ha descubierto la existencia de diversos problemas de seguridad en
varias implementaciones de SSH. Algunas de estas vulnerabilidades pueden
ser utilizadas para la ejecución de código arbitrario con los
privilegios del proceso SSH. Las vulnerabilidades afectan tanto a
clientes como servidores.

SSH, Secure Shell, es un protocolo cliente/servidor que permite el
establecimiento de conexiones entre dos sistemas, cifrando todo el
transporte de datos. Si bien SSH se utiliza habitualmente como un
sustituto de Telnet cuando la conexión debe pasar por redes hostiles
(como Internet), SSH ofrece muchas más posibilidades. Así, es posible la
transferencia segura de archivos, la ejecución remota de órdenes y el
redireccionamiento de puertos. Además, con SSH se pueden establecer
mecanismos fuertes de autenticación de usuarios y sistemas, mediante la
utilización de certificados digitales.

SSH fue inicialmente desarrollado en 1995 por Tatu Ylönen, de la
universidad de Helsinki (Finlandia) con el objetivo de impedir la
intercepción de las contraseñas que circulaban en claro en la red. A lo
largo de los años, SSH ha ido evolucionando hasta el punto de
convertirse en una propuesta de protocolo estándar.

A partir de la implementación original de SSH, hoy totalmente desfasada,
han surgido un gran número de implementaciones desarrolladas por la
empresa SSH Communications Security, así como por otras empresas.
Destaca, especialmente, la implementación de código abierto desarrollada
dentro del proyecto OpenSSH.

Se ha anunciado la existencia de diversas vulnerabilidades en algunas
implementaciones de SSH, que pueden provocar el desbordamiento de búfer
y, en algunos casos, la ejecución de código arbitrario con los
privilegios del proceso SSH vulnerable. Estas vulnerabilidades pueden
ser utilizadas indistintamente contra un servidor SSH como contra un
cliente SSH.

Las vulnerabilidades se encuentran en un tratamiento incorrecto de
paquetes que tienen diversos campos con una longitud no válida, vacíos,
con separadores o bien utilizando cadenas de texto conteniendo
únicamente caracteres NULL. Estas vulnerabilidades se encuentran en el
código responsable de la inicialización de las comunicaciones y en el
intercambio de claves.

Las implementaciones de SSH que parecen ser vulnerables son las
realizadas por Pragma Systems (Pragma SecureShell 2.0), PuTTY (versiones
anteriores a la 0.53b), F-Secure (servidores y clientes para Unix,
versiones anteriores a la 3.1.0 build 11), F- Secure para Windows
(versiones anteriores a la 5.2), SSH para Windows y Unix (versiones
anteriores a la 3.2.2), FiSSH 1.0A y anteriores, SecureNetTerm v5.4.1 y
anteriores, ShellGuard 3.4.6 y anteriores y WinSCP v2.0 y anteriores.

No obstante, debemos indicar que existe una disparidad en las
informaciones publicadas. Así, el aviso publicado por Rapid 7 indica los
productos que indicamos en el párrafo anterior, mientras que en el aviso
publicado por el CERT únicamente se reconocen como vulnerables Pragma
SecureShell, F-Secure y PuTTY.

Rapid 7 ha publicado un banco de pruebas, denominado SSHredder, que
permite comprobar si una implementación es vulnerable a los ataques. Se
trata de diversos paquetes que deben enviarse al cliente o servidor SSH,
utilizando netcat o una herramienta equivalente.


Xavier Caballé
xavi@hispasec.com



lunes, 16 de diciembre de 2002

Los peligros de convertirse en hacker; sesiones educativas en la escuela

Nace una iniciativa ciertamente original. Presentar a los adolescentes
el mundo de los hackers, pero de una forma en que sean conscientes de
los peligros que puede suponer para ellos. El objetivo, ayudarles a que
no utilicen sus conocimientos para realizar actividades delictivas y los
orienten al aspecto positivo que, sin duda, existe.

Imaginemos la escena: un adolescente, con acceso a un ordenador, un
módem (o una conexión de alta velocidad) y tiempo libre. A este
adolescente le llegan todo tipo de influencias y estímulos acerca el
mundo de los hackers. La mayoría hacen que un hacker se convierta en un
ídolo: las películas en la que los hackers acceden a cualquier ordenador
o cambian sus notas, las noticias y las leyendas urbanas acerca de las
aventuras que se pueden vivir en un ordenador conectado a Internet.

Muchos de estos adolescentes se sentirán intrigados y empezaran a buscar
información en la red. No les será difícil localizarla. En este punto,
el adolescente se ha convertido en una bomba en potencia. Como muy bien
explican en ISECOM, para los hackers el problema real no es que utilicen
sus conocimientos, sino que deben hacerlo de la forma correcta.

Convertirse en un hacker supone un esfuerzo intelectual que, bien
aprovechado, es muy positivo para la formación del adolescente. Se trata
de conseguir una visión de la tecnología que les será extremadamente
útil en caso de querer orientarse profesionalmente en el mundo de la
tecnología, las comunicaciones e Internet. Históricamente lo que ha
distinguido siempre a los hackers no es si son buenos o malos, sino su
inteligencia.

Pero el problema surge cuando se hacen las cosas mal. Una acción
realizada sin pensar en sus consecuencias, utilizando un programa recién
bajado de Internet que con un simple clic lanza un ataque contra esa
web, puede marcar negativamente el futuro.

Así, de la misma forma en que se enseña educación vial en las escuelas,
donde se facilitan los conocimientos adecuados para poder moverse por
nuestro mundo físico, nace la "Hacker High School".

Se trata de una sesión de formación, de unas 3 horas de duración, que
combina las charlas con la proyección de un cortometraje. Durante la
sesión, se presentarán los aspectos positivos que tiene el mundo de los
hackers, así como los riesgos que comporta hacer las cosas mal.

Además, se ofrecerá soporte a los profesores sobre los aspectos éticos y
legales de Internet, así como un plan de trabajo para continuar la
formación en las aulas. Opcionalmente también podrán tener acceso a una
red de prueba, en la que los alumnos podrán intentar aplicar sus
conocimientos de hacking. Esto será evaluado por un equipo de
profesionales de la seguridad, enviando los resultados a los profesores.
Esto permitirá identificar a aquellos adolescentes que, por sus
conocimientos, se encuentran en una situación de alto riesgo de forma
que los profesores puedan reorientar sus habilidades a favor del propio
adolescente.

Todo el proyecto de la "Hacker High School" ha sido desarrollado por
ISECOM (Institute for Security and Open Methodologies), una organización
internacional sin ánimo de lucro que trabaja en el desarrollo de
metodologías de libre utilización para la verificación de la seguridad,
la programación segura y la verificación de software. Para el entorno de
la red de prueba se ha contado con el patrocinio de Intense School, Inc.
Al tratarse de un organización sin ánimo de lucro, ISECOM se encuentra
receptiva a cualquier oferta de patrocinio o colaboración en este u
otros proyectos.

La primera sesión de la "Hacker High School" se celebra el próximo
martes 17 de diciembre en Barcelona, patrocinada por Enginyeria i
Arquitectura La Salle, de la universidad Ramon Llull.


Xavier Caballé
xavi@hispasec.com


Más información:

ISECOM Hacker High School
http://www.isecom.org/projects/hackerhighschool.htm

ISECOM (Institute for Security and Open Methodologies)
http://www.isecom.org/

domingo, 15 de diciembre de 2002

Fallo en Microsoft VM puede permitir comprometer el sistema

La máquina virtual java de Microsoft, ahora conocida como Microsoft VM,
forma parte de casi todas las versiones de Windows, así como en la
mayor parte de versiones de Internet Explorer. Microsoft ha publicado
una nueva versión de Microsoft VM que incluye todos los parches
anteriormente publicados para ella, así como las correcciones
necesarias para ocho nuevas vulnerabilidades.

Para explotar las nuevas vulnerabilidades, en todos los casos el ataque
se realizará de una forma muy parecida. El atacante debe crear una
página web maliciosa que, en el momento de visualizarla, podrá utilizar
la vulnerabilidad. El ataque podrá desarrollarse desde una página
alojada en un servidor web que se visite con un navegador, o bien en un
mensaje en formato HTML.

Las vulnerabilidades son las siguientes:

* Una vulnerabilidad por la cual un applet Java en el que no se confía
dispone de acceso a objetos COM.
* Dos vulnerabilidades que permitirán encubrir la localización actual
del codebase de los applets, con el objeto de hacer creer a la VM que
residen en el sistema local del usuario o bien en un recurso compartido
de la red.
* Una vulnerabilidad que podrá permitir a un atacante construir una URL
que cuando sea analizada podrá cargar un applet de Java desde un sitio
web pero falseándolo para que parezca que pertenece a otro sitio web.
* Una vulnerabilidad que se produce como consecuencia de que Microsoft
VM no impide a los applets acceder a la API de JDBC, de forma que podrá
añadir, cambiar, borrar o modificar el contenido de bases de datos con
la única limitación de los permisos del usuario.
* Una vulnerabilidad por la cual un atacante podrá evitar de forma
temporal la carga y ejecución de objetos Java concretos.
* Una vulnerabilidad que podrá permitir a un atacante conocer el nombre
del usuario en el sistema local.
* Una vulnerabilidad que resulta porque es posible que un applet Java
realizar una inicialización incompleta de otro Java. Como consecuencia
de esta vulnerabilidad, la aplicación contenedora (Internet Explorer),
dejará de funcionar.

De todas estas vulnerabilidades, la primera se considera como crítica
ya que puede llegar a ser utilizada por un atacante remoto para
conseguir el control completo del sistema vulnerable.

Los parches necesarios se encuentran disponibles a través de Windows
Update: http://windowsupdate.microsoft.com/


Antonio Ropero
antonior@hispasec.com


Más información:

Flaw in Microsoft VM Could Enable System Compromise:
http://www.microsoft.com/technet/security/bulletin/MS02-069.asp

MS02-069: Flaw in Microsoft VM May Compromise Windows
http://support.microsoft.com/default.aspx?scid=kb;en-us;810030

Your Microsoft critical security patches tonight
http://www.theregister.co.uk/content/55/28546.html

sábado, 14 de diciembre de 2002

Elevación de privilegios en Windows NT 4.0, 2000 y XP por vulnerabilidad en mensajes WM_TIMER

Los mensajes Windows proporcionan una forma para que los procesos
interactivos reaccionen a los eventos del usuario (por ejemplo,
pulsaciones de teclado o movimientos del ratón) y comunicarse con otros
procesos interactivos. Uno de estos mensajes, concretamente WM_TIMER
que se envía al expirar un intervalo de tiempo, puede ser utilizado
para que un proceso ejecute una función de llamada
retorno.

Se produce una vulnerabilidad de seguridad debido a la posibilidad de
que un proceso en el desktop interactivo use un mensaje WM_TIMER para
provocar que otro proceso ejecute una función de llamada de retorno de
su elección, incluso si el segundo proceso no tiene ajustado un
temporizador. Si el segundo proceso tiene privilegios más altos que el
primero, este podrá proporcionar al primer proceso una forma de
ejecutarlo.

Por defecto, muchos de los procesos ejecutados en el desktop
interactivo lo hacen con privilegios LocalSystem. Como resultado, un
atacante con la posibilidad de acceder al sistema de forma interactiva
podrá ejecutar un programa que permita realizar una petición WM_TIMER
bajo dicho proceso, permitiendo al atacante realizar cualquier acción
y tomar el control del sistema.

Actualizaciones publicadas por Microsoft:

Windows NT 4.0
http://microsoft.com/downloads/details.aspx?FamilyId=E5606A46-364E-4585-9EDB-63654007E685&displaylang=en

Windows NT 4.0, Terminal Server Edition
http://microsoft.com/downloads/details.aspx?FamilyId=5A203864-F6DF-41EB-A8DB-13EFFCD84081&displaylang=en

Windows 2000
http://microsoft.com/downloads/details.aspx?FamilyId=C663A0EA-F6CB-4EE1-8AFA-0C068F84A1D5&displaylang=en

Windows XP 32-bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=98F02C55-E598-4EB1-AABE-DB3BA0807685&displaylang=en

Windows XP 64-bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=4D97D23B-6773-4EA4-AF2E-C97FA52E04BE&displaylang=en



Antonio Ropero
antonior@hispasec.com


Más información:

Boletín de seguridad de Microsoft (MS02-071)
Flaw in Windows WM_TIMER Message Handling Could Enable Privilege
Elevation
http://www.microsoft.com/technet/security/bulletin/MS02-071.asp
http://www.microsoft.com/security/security_bulletins/ms02-071.asp

MS02-071: Flaw in Windows WM_TIMER Message Handling Can Enable
Privilege Elevation
http://support.microsoft.com/default.aspx?scid=kb;en-us;328310

Information About Reported Architectural Flaw i
Windows
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/Security/news/htshat.asp

Interactive Services (información acerca del Deskto
interactivo)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/interactive_services.asp

viernes, 13 de diciembre de 2002

Fallo en la firma SMB permite la modificación de políticas de grupo

Un error en la implementación del firmado SMB en Windows 2000 y
Windows XP puede permitir a un atacante modificar la configuración
de firmado SMB en los sistemas Windows 2000 y Windows XP.

Para explotar la vulnerabilidad el atacante necesita acceso a los
datos de negociación de sesión tal como fueron intercambiados entre
un cliente y el servidor, tras lo cual necesitará modificar los datos
de forma apropiada. Tras alterar los parámetros de firmado, el
atacante podrá llevar a cabo cualquier otra acción maliciosa dentro
de las sesiones SMB, como escuchar las comunicaciones o modificarlas.

Aunque esta vulnerabilidad puede explotarse para intentar forzar
cualquier sesión SMB de intercambio de archivos, también puede
emplearse para la modificación de políticas de grupo. Esto puede
permitir a un atacante añadir usuarios al grupo de administración
y de esta forma tomar el control del sistema.

Los parches proporcionados por Microsoft se encuentran disponibles en:
Para Microsoft Windows 2000:
http://microsoft.com/downloads/details.aspx?FamilyId=52EAC216-A360-4E2D-9C6B-AD4D31C40BA2&displaylang=en
Para Windows XP edición 32 bit:
http://microsoft.com/downloads/details.aspx?FamilyId=77B49431-742B-4426-AD45-F09D3AED16CB&displaylang=en
Para Windows XP edición 64 bit:
http://microsoft.com/downloads/details.aspx?FamilyId=580FCE68-B7E2-4BF9-8A16-54D1E39F2168&displaylang=en


Antonio Ropero
antonior@hispasec.com


Más información:

Flaw in SMB Signing Could Enable Group Policy to be Modified
http://www.microsoft.com/technet/security/bulletin/MS02-070.asp

jueves, 12 de diciembre de 2002

Usuarios de eBay objetivo de un espectacular intento de fraude

La mayor casa de subastas del mundo a comunicado que sus 55 millones de
clientes han estado en el punto de mira de un espectacular fraude.

Para la realización de este fraude los estafadores solicitaban por
correo electrónico a algunos clientes sus datos personales, con la
aparente finalidad de realizar una comprobación. Para ello, los usuarios
debían dirigirse a la dirección ebayupdate, donde los clientes engañados
debían introducir sus datos para proceder a su verificación con la
excusa de una comprobación técnica. Para llevar a cabo este fraude los
atacantes empleaban un método ya muy conocido en los ámbitos de la
seguridad informática, la "ingenieria social" .

"Algunos usuarios de nuestro servicio han denunciado intentos para
obtener acceso a su información personal en solicitudes con mensajes de
correo electrónico que, falsamente, parecen enviados por eBay", dijo la
compañía en un comunicado. "Estas solicitudes a menudo contienen enlaces
a paginas del Web en las que se les pedirá que de su información
personal... los empleados de eBay nunca le pedirán su contraseña",
aseguran.

El fraudulento mensaje lleva como encabezamiento "Error de su cuenta de
Ebay" y comienza: "Distinguido miembro de Ebay (escrito así). Nosotros
en Ebay sentimos informarle que estamos teniendo problemas con la
información de cobro de su cuenta".

Desde Hispasec Sistemas recomendamos a todos nuestros lectores que
siempre desconfíen ante este tipo de peticiones, ya que ninguna compañía
seria utilizaría estos métodos de comprobación.


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


Más información:


eBay denuncia el intento de robo de los datos de sus 55 millones de
clientes
http://www.elmundo.es/navegante/2002/12/11/seguridad/1039605160.html

Advertencia sobre fraude a clientes de eBay en Internet
http://es.news.yahoo.com/021211/44/2dvdg.html

miércoles, 11 de diciembre de 2002

Datos de millones de usuarios expuestos por un fallo de programación web

Un error de programación en una de las páginas asp del comercio
electrónico Tower Records dejaba los datos de millones de usuarios
expuestos ante cualquier otro usuario.

Un fallo de programación en la tienda on-line Tower Records
(http://www.towerrecords.com/) permitía de una forma sencilla el acceso
de cualquier usuario a los datos de otros usuarios. Datos como nombre y
apellidos, dirección física y dirección de e-mail, teléfono y los
pedidos realizados quedaban a la vista mediante una simple modificación
de una URL. El problema permitía acceder a más de tres millones de
registros de este tipo.

La robustez de un sitio web no depende en exclusiva de instalar
correctamente el servidor y corregir las continuas vulnerabilidades que
aparecen para su sistema operativo y los servicios instalados. Muchos
ataques e intrusiones a servidores Internet se realizan a través de las
aplicaciones propietarias que soportan las soluciones finales: páginas
web/ASP, scripts, acceso a base de datos, componentes propietarios, etc.
Junto a los administradores, los desarrolladores y webmasters son
responsables directos de la seguridad del sitio web.

Recientemente informamos sobre la publicación de una guía de referencia
para facilitar el desarrollo de aplicaciones web. Una vez más se
evidencia la necesidad de mejorar la calidad en la programación de las
páginas web. El fallo, que se encontraba en la página "orderStatus.asp",
fue corregido a las pocas horas de tener conocimiento del problema,
según comunicaron los responsables del sitio web.


Antonio Ropero
antonior@hispasec.com


Más información:

Tower Records site exposes data
http://news.com.com/2100-1017-976271.html

una-al-dia (04/12/2002) Guía para el desarrollo de aplicaciones web
seguras
http://www.hispasec.com/unaaldiacom.asp?id=1501

una-al-dia (30/09/2001) Curso de seguridad para desarrolladores y
webmasters
http://www.hispasec.com/unaaldia.asp?id=1071

martes, 10 de diciembre de 2002

Acceso remoto como administrador a servidores Cobalt RaQ 4

Se ha descubierto una vulnerabilidad que puede ser utilizada para
acceder, como root, a un servidor Sun Cobatl RaQ 4 donde se haya
instalado el paquete SHP.

Los equipos Cobalt RaQ 4de Sun son unas "appliances" (es decir, una
combinación de hardware y software especializado para realizar una tarea
concreta). Se trata de unos ordenadores PC estándar, ejecutando un
sistema operativo Linux, con un sofisticado sistema de administración
vía web. Estos equipos son muy utilizados por los ISP especializados en
servicios de hosting, así como por empresas que desean disponer de un
servidor de bajo coste y fácilmente administrable.

Los equipos afectados son aquellos en los que se ha instalado un
componente opcional del sistema operativo, el Security Hardening
Package. La vulnerabilidad se encuentra en uno de los CGI de
administración remota (/cgi-bin/.cobalt/overflow/overflow.cgi) que no
realiza las comprobaciones adecuadas en los parámetros. Como
consecuencia de ello, un atacante puede enviar una petición POST a este
CGI que provocará un desbordamiento de buffer y la ejecución del código
enviado con privilegios de root.

Sun ha publicado la actualización necesaria para evitar el problema.
Ésta debe ser instalada, lo antes posible, en todos aquellos equipos
Cobalt RaQ 4 donde se haya instalado el paquete SHP, ya que se han
publicado diversos exploits para aprovechar esta vulnerabilidad.


Xavier Caballé
xavi@hispasec.com



lunes, 9 de diciembre de 2002

Actualizaciones de seguridad en KDE

En los últimos meses se han dado a conocer diversas vulnerabilidades de
seguridad en KDE.

KDE (K Desktop Environment) proporciona un entorno de escritorio gráfico
en los sistemas operativos Unix. Se trata de un proyecto de código
abierto, muy maduro y de gran calidad.

En los últimos meses, desde agosto a noviembre del presente año, se han
dado a conocer diversas vulnerabilidades de seguridad:


Vulnerabilidad en LISa

Kdenetwork es el componente de KDE encargado de la comunicación entre
los diferentes equipos que ejecuten KDE en una misma red, utilizando
URL del tipo lan:// y rlan://

Este componente utiliza dos daemons: LISa (el daemon principal) y
resLISa (una versión con permisos restringidos). Se ha descubierto la
existencia de un desbordamiento de memoria intermedia en resLISa que
puede ser utilizada por un usuario local para obtener privilegios de
root en el sistema vulnerable.

La vulnerabilidad podría llegar a ser utilizada por un atacante remoto
para obtener acceso a la máquina vulnerable mediante la utilización de
las URL lan:// en una página web o una aplicación KDE.

Esta vulnerabilidad afecta a todas las versiones de KDE 2 y a las
versiones de KDE 3 anteriores a la 3.0.4 y 3.1rc3 (incluidas). La
vulnerabilidad ha sido solucionada en la versión 3.0.5 y existe un
parche para la versión 3.0.4.


Vulnerabilidad en KIO

KDE da soporte a diversos protocolos de red a través del subsistema KIO.
Estos protocolos son implementados mediante archivos de texto con la
extensión .protocol, habitualmente en el directorio shared/services/
dentro del directorio raíz de KDE.

La implementación de diversos protocolos (rlogin en todas las versiones
afectadas y telnet en las versiones de KDE 2) puede ser utilizada por un
atacante remoto para ejecutar código arbitrario en las máquinas
vulnerables.

Esta vulnerabilidad afecta a todas las versiones de KDE posteriores a la
2.1 así como a todas las versiones de KDE 3 anteriores a la 3.0.4 y
3.1rc3 (inclusive). La vulnerabilidad ha sido solucionada en la versión
3.0.5 y existe un parche para la versión 3.0.4. Se recomienda a los
usuarios de versiones anteriores de KDE 3 la actualización a la versión
3.0.5, mientras que en el caso de los usuarios de KDE 2 se recomienda
desactivar los protocolos telnet y rlogin en KIO.


Escalada de directorios en kpf

kpf es una utilidad para compartición de archivos que puede asociarse a
la barra de tareas de KDE. Internamente su funcionamiento es muy
parecido al de un servidor web y utiliza un subconjunto del protocolo
HTTP.

Existe una vulnerabilidad en las versiones de kpf posteriores a la 3.0.1
y anteriores a la 3.0.3a que puede ser utilizada por un atacante remoto
para acceder, en modalidad de lectura, a cualquier archivo incluso si no
está expresamente compartido.


Ejecución arbitraria de código en Kghostview

Kghostview es el visualizador de archivos PostScript y PDF incluido en
KDE. Las versiones para cualquier versión de KDE entre la 1.1 y la
3.0.3a tienen un desbordamiento de memoria intermedia que puede ser
utilizado para ejecutar código arbitrario, con los privilegios del
usuario que visualiza el archivo PostScript/PDF, en la máquina
vulnerable.

Hay disponible un parche, aunque se recomienda la actualización a la
versión 3.0.5 de KDE.


Vulnerabilidad Cross Site Scripting en Konqueror

Existe una vulnerabilidad del tipo Cross Site Scripting en las versiones
de Konqueror incluidas en KDE 2 (versión 2.2) y KDE 3 (versiones entre
la 3.0 y la 3.0.3) que puede ser utilizada por un JavaScript desde un
frame o un iframe para acceder a la información de otros dominios.

Esta vulnerabilidad afecta a Konqueror así como a cualquier otra
aplicación que utilice el sistema de presentación KHTML.

Se recomienda la actualización a la versión 3.0.5 de KDE.


Konqueror no reconoce el campo "Secure" en las cookies

Konqueror no reconoce el campo "Secure" de la cabecera de las cookies.
Como consecuencia de ello, es posible enviar en una sesión HTTP
estándar, sin cifrado, cookies que contienen información confidencial.

Esta vulnerabilidad afecta a las versiones de Konqueror incluidas en KDE
3.0, 3.0.1 y 3.0.2.

Se recomienda la actualización a la versión 3.0.5 de KDE.


Errores en el reconocimiento de certificados SSL

La implementación de SSL de KDE (versiones anteriores a la 3.0.2) no
realiza las comprobaciones adecuadas en los certificados. Como
consecuencia de ello es posible que un certificado erróneo o que no hay
sido firmado por la supuesta autoridad certificadora, sea considerado
como válido.

Se recomienda actualizar a la versión 3.0.5 de KDE.


Xavier Caballé
xavi@hispasec.com


Más información:

KDE Security Advisory: resLISa / LISa Vulnerabilities
http://www.kde.org/info/security/advisory-20021111-2.txt

KDE Security Advisory: rlogin.protocol and telnet.protocol URL KIO Vulmerability
http://www.kde.org/info/security/advisory-20021111-1.txt

KDE Security Advisory: kpf Directory traversal
http://www.kde.org/info/security/advisory-20021008-2.txt

KDE Security Advisory: Konqueror Cross Site Scripting Vulnerability
http://www.kde.org/info/security/advisory-20020908-2.txt

KDE Security Adivsory: Secure Cookie Vulnerability
http://www.kde.org/info/security/advisory-20020908-1.txt

KDE Security Advisory: Konqueror SSL vulnerability
http://www.kde.org/info/security/advisory-20020818-1.txt

RedHat updates to KDE
http://www.secunia.com/advisories/7650/

KDE KIO Protocol Subsystem Bugs May Let Remote Users Execute Arbitrary Commands
http://www.securitytracker.com/alerts/2002/Nov/1005609.html

Updated KDE packages fix security issues
https://listman.redhat.com/pipermail/redhat-watch-list/2002-December/000602.html

SuSE Security Advisory: kdenetwork
http://www.suse.com/de/security/2002_042_kdenetwork.html

domingo, 8 de diciembre de 2002

Disponible PGP versión 8.0

Acaba de publicarse una nueva versión de PGP, el auténtico estándar para
el cifrado del correo electrónico. Esta versión significa también la
recuperación de algunas de las viejas y añoradas buenas prácticas.

PGP, Pretty Good Pricacy, nació hacia el año 1991 por iniciativa de Phil
Zimmermann con el objetivo de facilitar un software que permitiera el
cifrado de documentos de una forma fiable. Durante los primeros años,
hasta el 1996, PGP tuvo una serie de problemas con el gobierno
norteamericano, que consideraba la criptografía como una tecnología de
utilización restringida y con diversas empresas al considerar que el
producto no respetaba diversas patentes. Finalizados estos litigios,
Phil Zimmermann fundó la empresa PGP Inc con el objetivo de ofrecer
servicios asociados al producto, aunque manteniendo las versiones
gratuitas del mismo.

En 1997 la empresa PGP fue adquirida por Network Associates (NAI). A
causa de las dificultades del mercado, NAI decidió a finales del año
pasado poner los activos de la antigua PGP Inc a la venta. Ante la falta
de ofertas, NAI anunció en marzo de este año que dejaba de desarrollar y
vender la línea de productos de cifrado de PGP. En agosto de este año se
fundó una nueva empresa, PGP Corporation, que adquirió los derechos de
los productos de cifrado de NAI.

Una de las primeras medidas que anunció la nueva empresa fue la
publicación, para antes de finales del presente año, de una nueva
versión de PGP. La principal novedad de esta versión es el soporte de
las últimas versiones de los sistemas operativos Windows XP y Mac OS.

Pero hay más. Mientras la línea de productos PGP era propiedad de NAI,
esta empresa decidió dejar de publicar el código fuente de las últimas
versiones del producto (7.1.x). Esta decisión se consideró como un
ataque a la transparencia que hasta la fecha siempre había tenido PGP.
Disponer del código fuente del producto es una garantía de que no
existen puertas secretas en el mismo, así como de conocer su forma de
trabajar. NAI también se retrasaba muchos meses en la publicación de las
versiones freeware del producto.

Con la nueva versión 8.0 del producto también se han publicado, el mismo
día, el código fuente del producto así como la versión freeware. No
obstante, conviene precisar que la versión freeware no es equivalente al
producto comercial ya que carece de los plug-ins para la integración con
los programas de correo electrónico y mensajería instantánea y tampoco
incluye PGP Disk, el cual permite crear discos virtuales cuyo contenido
se encuentra constantemente cifrado.


Xavier Caballé
xavi@hispasec.com



sábado, 7 de diciembre de 2002

Problema en el procesamiento de cabeceras de correo de Outlook 2002

Un problema en el procesamiento de cabeceras de Outlook 2002 puede
permitir a un atacante impedir el uso de este programa para recuperar
los mensajes de correo.

Microsoft Outlook proporciona a los usuarios la posibilidad de
trabajar con correo e-mail, contactos, tareas y citas. El tratamiento
de e-mail de Outlook incluye aspectos como recepción, presentación,
creación, edición, envío y organización de los mensajes. Al trabajar
con los mensajes recibidos, Outlook procesa la información contenida
en la cabecera del e-mail, que incluye datos sobre de donde llega el
e-mail, su destino y los atributos del mensaje.

La vulnerabilidad anunciada por Microsoft se presenta en Outlook 2002
en el procesamiento de la información de las cabeceras de los correos.
Un atacante que logre explotar de forma exitosa esta vulnerabilidad
podrá enviar un mensaje a un usuario de Outlook 2002 construido de
forma que el cliente falle. El cliente Outlook 2002 continuará
fallando mientras que el mensaje especialmente construido continúe en
el servidor de correo.

El mensaje malicioso deberá ser eliminado por el administrador o
mediante el uso de otro cliente de correo.

La actualización necesaria para evitar este problema se encuentra
disponible en: http://office.microsoft.com/downloads/2002/olk1005.aspx


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin MS02-067
E-mail Header Processing Flaw Could Cause Outlook 2002 to Fail
http://www.microsoft.com/technet/security/bulletin/MS02-067.asp

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

viernes, 6 de diciembre de 2002

Nuevo parche acumulativo para Internet Explorer

Microsoft publica un nuevo parche acumulativo para Internet Explorer 5.5
y 6.0. Además de incluir las funcionalidades de todos los parches
previamente publicados para Internet Explorer 5.5 y 6.0, también elimina
una nueva vulnerabilidad en el modelo de seguridad de transferencia entre
dominios.

El fallo se presenta debido a que no se realizan los adecuados controles
de seguridad que Internet Explorer lleva a cabo cuando se emplean
determinadas técnicas de caché de objetos. Esto podrá permitir a un
sitio web en un dominio acceder a información de otro dominio, incluido
el sistema local del usuario.

Explotar esta vulnerabilidad podrá permitir a un atacante la lectura (no
modificación) de cualquier archivo situado en el disco duro del usuario
que visite la página web maliciosa. También se podrá lograr la ejecución
de cualquier ejecutable, siempre que se conozca su localización exacta,
y no podrá pasarle ningún parámetro.

Microsoft publica los parches necesarios para evitar este problema (y
todos las vulnerabilidades anteriores) en todos los idiomas, incluida la
versión española, en la dirección:
http://www.microsoft.com/windows/ie/downloads/critical/q324929/default.asp


Antonio Ropero
antonior@hispasec.com


Más información:

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

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

December 2002, Cumulative Patch for Internet Explorer (Q324929)
http://www.microsoft.com/windows/ie/downloads/critical/q324929/default.asp

jueves, 5 de diciembre de 2002

Vulnerabilidad en sistemas de telefonía IP de 3Com

Los sistemas de telefonía IP NBX y NBX 100 de 3Com pueden ser bloqueados
por un atacante remoto, consiguiendo la denegación del servicio y,
potencialmente, la corrupción de los mensajes almacenados.

Los equipos NBX y NBX 100 proporcionan un conjunto de funcionalidades
de procesamiento de llamadas telefónicas, con una amplia gama de
aplicaciones de telefonía, hasta un máximo de 1500 dispositivos
(líneas/estaciones). Estos equipos ofrecen prestaciones avanzadas de
forma integrada, como la gestión de buzones de voz, autooperadoras,
grupos de salto, generación de informes de utilización del teléfono,
integración del buzón de voz con el correo electrónico y un largo
etcétera.

Estos equipos, auténticos ordenadores, utilizan un sistema operativo en
tiempo real llamado VxWorks, derivado de Unix, que dispone de un
servidor ftp para permitir la transferencia de datos desde la centralita
telefónica a la red de datos.

Se ha descubierto la existencia de una vulnerabilidad de denegación de
servicio en dicho servidor ftp. Un atacante que envíe una orden CEL
con un argumento de 2048 bytes de longitud, provocará la detención
inesperada del servidor ftp. Otros componentes críticos, como la consola
de administración vía web y el gestor de llamadas. Esto impedirá la
administración de las llamadas telefónicas, incluyendo los diagnósticos
y el control de llamadas entrantes y salientes.

La única forma de recuperar el funcionamiento normal será mediante una
reinicialización en frío del sistema. Esto tiene el inconveniente que
puede potencialmente originar la corrupción de datos, como los mensajes
de voz o los registros de llamadas telefónicas.


Xavier Caballé
xavi@hispasec.com



miércoles, 4 de diciembre de 2002

Guía para el desarrollo de aplicaciones web seguras

Se publica una guía de referencia para facilitar el desarrollo de
aplicaciones web teniendo en cuenta, desde el mismo momento en que se
realiza el diseño de las mismas.

En los últimos meses estamos asistiendo a un considerable movimiento
alrededor de las aplicaciones y los servicios web. Casi todos los
fabricantes de software están orientando sus plataformas de desarrollo
de aplicaciones para que se integren y utilicen las posibilidades de la
web.

Entendemos por aplicaciones web a todo aquél software que interacciona
con el usuario utilizando el protocolo HTTP. Por su parte, los servicios
web son un conjunto de funciones empaquetadas dentro de una entidad
única y publicadas dentro de la red para que puedan ser utilizadas por
las aplicaciones web.


Normas básicas de seguridad

El proyecto OWASP (Open Web Application Security Project) tiene como
objetivo ofrecer una metodología, de libre acceso y utilización, que
pueda ser utilizada como material de referencia por parte de los
arquitectos de software, desarrolladores, fabricantes y profesionales
de la seguridad involucrados en el diseño, desarrollo, despliegue y
verificación de la seguridad de las aplicaciones y servicios web.

La guía empieza estableciendo los principios básicos de seguridad que
cualquier aplicación o servicio web debe cumplir:

* Validación de la entrada y salida de información
La entrada y salida de información es el principal mecanismo que dispone
un atacante para enviar o recibir código malicioso contra el sistema.
Por tanto, siempre debe verificarse que cualquier dato entrante o
saliente es apropiado y en el formato que se espera. Las características
de estos datos deben estar predefinidas y debe verificarse en todas las
ocasiones.

* Diseños simples
Los mecanismos de seguridad deben diseñarse para que sean los más
sencillos posibles, huyendo de sofisticaciones que compliquen
excesivamente la vida a los usuarios. Si los pasos necesarios para
proteger de forma adecuada una función o modulo son muy complejos, la
probabilidad de que estos pasos no se ejecuten de forma adecuada es muy
elevada.

* Utilización y reutilización de componentes de confianza
Debe evitarse reinventar la rueda constantemente. Por tanto, cuando
exista un componente que resuelva un problema de forma correcta, lo más
inteligente es utilizarlo.

* Defensa en profundidad
Nunca confiar en que un componente realizará su función de forma
permanente y ante cualquier situación. Hemos de disponer de los
mecanismos de seguridad suficientes para que cuando un componente del
sistema fallen ante un determinado evento, otros sean capaces de
detectarlo.

* Tan seguros como en eslabón más débil
La frase "garantizamos la seguridad, ya que se utiliza SSL" es realmente
muy popular, pero también es muy inexacta. La utilización de SSL
garantiza que el tráfico en tránsito entre el servidor y el cliente se
encuentra cifrado, pero no garantiza nada acerca de los mecanismos de
seguridad existentes.

Por tanto, no debemos fiarnos únicamente de los mecanismos de seguridad
"exteriores", sino que es preciso identificar cuales son los puntos
precisos en los que deben establecerse las medidas de seguridad. Si
nosotros no hacemos este trabajo, seguro que los atacantes si lo harán.

* La "seguridad gracias al desconocimiento" no funciona
El simple hecho de ocultar algo no impide que, a medio o largo plazo,
llegue a ser descubierto. Tampoco es ninguna garantía de que tampoco
será descubierto a corto plazo.

* Verificación de privilegios.
Los sistemas deben diseñarse para que funcionen con los menos
privilegios posibles. Igualmente, es importante que los procesos
únicamente dispongan de los privilegios necesarios para desarrollar su
función, de forma que queden compartimentados.

* Ofrecer la mínima información
Ante una situación de error o una validación negativa, los mecanismos de
seguridad deben diseñarse para que faciliten la mínima información
posible. De la misma forma, estos mecanismos deben estar diseñados para
que una vez denegada una operación, cualquier operación posterior sea
igualmente denegada.

Otros aspectos tratados en la guía son: consideraciones de arquitectura,
mecanismos de autenticación, gestión de sesiones de usuario, control de
acceso, registro de actividad, prevención de problemas comunes,
consideraciones de privacidad y criptografía.


Xavier Caballé
xavi@hispasec.com



martes, 3 de diciembre de 2002

Call for papers CIBSI'03 - México

A continuación reproducimos la primera llamada para ponencias de
CIBSI'03, Segundo Congreso Iberoamericano de Seguridad Informática,
que se celebrará en México DF, del 28 al 31 de octubre de 2003.

Tras el éxito del Primer Congreso celebrado en la ciudad de Morelia,
México, la Escuela Superior de Cómputo del Instituto Politécnico
Nacional será la anfitriona de la segunda edición, teniendo también
como instituciones organizadoras a la Universidad Nacional Autónoma
de México, el Instituto Tecnológico de Morelia y la Universidad
Politécnica de Madrid.

En esta segunda edición, además de la presentación de ponencias por
parte de investigadores de toda Latinoamérica, España y Portugal, se
contará con la participación de destacados expertos como
conferenciantes invitados, habiendo confirmado su participación el
Dr. Alfred Menezes de la Universidad de Waterloo, Canadá, el Dr. René
Peralta de la Universidad de Yale, EEUU, y el Dr. Adriano Mauro
Cansian de la Universidad Estadual Paulista, Brasil. Asimismo,
durante este evento se celebrará la primera asamblea general de
miembros de la Red Temática Iberoamericana de Criptografía y
Seguridad de la Información, CriptoRed.

Temas de interés: (más detallada en http://www.escom.ipn.mx/cibsi/)

Administración de Redes
Criptografía y Criptoanálisis
Análisis Forense
Arquitecturas de Seguridad
Auditoría Informática
Certificaciones de Seguridad
Código Malicioso y Virus
Comercio Electrónico Seguro
Criptografía con Curvas Elípticas
Delitos Informáticos
Detección de Intrusiones
Estándares de Seguridad
Infraestructuras de Llave Pública
Legislación en Seguridad
Notarización Electrónica
Políticas de Seguridad
Protocolos Criptográficos
Protecciones de Red y Cortafuegos
Redes Privadas Virtuales
Seguridad en Agentes Móviles
Seguridad en Bases de Datos
Seguridad en Redes Inalámbricas
Seguridad en Sistemas Operativos
Servidores y Redes Seguras
Sistemas de Autenticación
Tarjetas Inteligentes
Votaciones Electrónicas

Fechas:

Final de la convocatoria para el envío de trabajos: 30 de junio de 2003
Notificación de aceptación y petición correcciones: 31 de julio de 2003
Notificación de aceptación definitiva: 15 de septiembre de 2003.

Instrucciones para los autores:

Los trabajos se enviarán a la siguiente dirección de e-mail:
cibsi@siberiano.aragon.unam.mx.
Para cualquier información adicional sobre formato, naturaleza de los
trabajos y otros aspectos de CIBSI ’03: jramio@eui.upm.es.

Todos los trabajos deben incluir: nombre del trabajo, nombre de los
autores, dirección postal, números de teléfono y fax, país de origen,
institución o empresa, dirección de correo electrónico. La estructura
del trabajo debe incluir al menos lo siguiente: resumen, antecedentes,
trabajos previos o relacionados, problema, propuesta o solución,
desarrollo, resultados, conclusiones, referencias.

Todos los trabajos deberán ser originales y estar contenidos en un
mínimo de 5 cuartillas y en un máximo de 15. El formato estándar
será PDF, según modelo que se puede descargar desde la página Web
de CIBSI ’03.

Actas del Congreso:

Las actas del congreso se publicarán con su correspondiente ISBN.
Sólo se publicarán los trabajos que hayan sido aceptados y expuestos
en el congreso.

Comité de Programa:

Javier Areito, U. de Deusto (España)
Pino Caballero, U. La Laguna (España)
Jeimy Cano, U. Los Andes (Colombia)
Hugo Coyote, I. P. Nacional (México)
Ricardo Dahab, UNICAMP (Brasil)
Jorge Dávila, U. P. Madrid (España)
Enrique Daltabuit, UNAM (México)
Jorge Estrada, ICIMAF (Cuba)
Amparo Fúster, CSIC (España)
Emilio Hernández, U. S. Bolívar (Venezuela)
Marco Henriques, UNICAMP (Brasil)
Javier López, U. Málaga (España)
Julio López, U. del Valle (Colombia)
Edmundo Monteiro, U. Coimbra (Portugal)
Arturo Ribagorda, U. Carlos III (España)
Hugo Scolnik, U. B. Aires (Argentina)
Miquel Soriano, U. P. Catalunya (España)
Horacio Tapia, UNAM (México)


Bernardo Quintero
bernardo@hispasec.com


Más información:

CIBSI'03
http://www.escom.ipn.mx/cibsi/

lunes, 2 de diciembre de 2002

Dos nuevas vulnerabilidades en el cortafuegos PIX de Cisco

Se han descubierto recientemente dos nuevas vulnerabilidades en el
cortafuegos PIX de Cisco. La primera de ellas puede permitir a un
usuario remoto establecer, en circunstancias muy concretas, una sesión
VPN no autorizada. La segunda vulnerabilidad puede permitir a un usuario
remoto detener inesperadamente el cortafuegos.

Cisco ha publicado un aviso para informar de la existencia de dos
vulnerabilidades en su cortafuegos PIX.

La primera de estas vulnerabilidades se encuentra en el mecanismo
utilizado por PIX para establecer las redes privadas virtuales (VPN).
Cuando un usuario, previamente autenticado, establece una sesión VPN, el
cortafuegos crea una asociación de seguridad (SA) entre el identificador
de usuario y la dirección IP.

Si un atacante es capaz de bloquear una conexión establecida de un
usuario y establecer él una conexión contra el cortafuegos PIX,
utilizando la misma dirección IP del usuario, podrá establecer una
sesión VPN disponiendo únicamente de las credenciales PSK o la
contraseña de grupo.

Esta vulnerabilidad afecta a las versiones de PIX anteriores a la 6.0.3
y a la 6.1.3.

La segunda vulnerabilidad es un posible desbordamiento de búfer en el
momento de procesar el tráfico HTPP con peticiones de autenticación
contra un servidor de autenticación TACACS+ o RADIUS. En determinadas
circunstancias, una petición de autenticación especialmente diseñada
puede provocar el desbordamiento de búfer, provocando la detención
inesperada del cortafuegos.

Las versiones de PIX afectadas por este problema son la 5.2.8 y
anteriores, la 6.0.3 y anteriores, la 6.1.3 y anteriores y la 6.2.1 y
anteriores.

Según informa Cisco, estas dos vulnerabilidades sólo pueden ser
eliminadas instalando las versiones actualizadas del software PIX: 5.2.9
o posterior, 6.0.4 o posterior, 6.1.4 o posterior y 6.2.2 o posterior.


Xavier Caballé
xavi@hispasec.com