jueves, 30 de septiembre de 1999

Vulnerabilidad "Download Behavior" en Internet Explorer 5 (I)

Microsoft confirma una nueva vulnerabilidad, descubierta por
Georgi Guninski, que permitiría a un sitio web leer ficheros
locales de los usuarios que visitan sus páginas con Internet
Explorer 5. El problema parte de una nueva característica que
incorpora el navegador conocida como "download behavior".
"Download behavior" es uno más de los nuevos componentes que
acompañan a Internet Explorer 5, y que no dejan de ser un
paso más en la política que Microsoft está aplicando a todas
sus plataformas, el encapsulamiento de elementos para, en
teoría, facilitar su distribución y utilización.

Esta característica posibilita que, a través de scripts
incluidos en las páginas webs, se puedan descargar ficheros
de forma directa sin la intervención y el conocimiento del
usuario. Como medida de seguridad, Microsoft restringe el
ámbito de aplicación, tan sólo permite que se puedan bajar
los ficheros que pertenezcan al mismo dominio del servidor
del que proviene la página web que contiene el script. Es
decir, en teoría esta restricción debería impedir que se pueda
acceder a los ficheros del sistema del usuario que visita la
web o de la intranet a la que éste pertenezca.

Sin embargo, Georgi Guninski, ya habitual en nuestras
noticias, ha demostrado que es posible burlar la restricciones
impuestas por Microsoft utilizando un CGI que redirecciona la
petición HTTP. En la demostración en su página podemos ver
como se utiliza a Internet Explorer como herramienta espía
para leer ficheros locales, en este caso el AUTOEXEC.BAT, de
los ordenadores que visiten la web.

Mientras Microsoft pone a disposición un nuevo parche para su
navegador que corriga esta vulnerabilidad, la solución para
los usuarios pasa por deshabilitar "Ejecutar controles y
complementos de ActiveX", a través de la opción de personalizar
el nivel de seguridad de Internet Explorer. Para llegar a este
apartado deberemos de elegir Opciones de Internet en el menú
Herramientas, y posicionarnos en la pestaña de Seguridad.

Más información:
Microsoft - Boletín (MS99-040)
Microsoft - FAQ (MS99-040)
Demostración por Georgi Guninski



Bernardo Quintero



miércoles, 29 de septiembre de 1999

Vulnerabilidad Solaris en la variable de entorno LC_MESSAGES

Sun Microsystems acaba de publicar parches para solucionar problemas de
desbordamiento de buffer a través de la variable de entorno LC_MESSAGES.
Estos ataques están siendo explotados en la actualidad, de forma activa,
y permiten obtener privilegios "root" en las máquinas afectadas.
El pasado 8 de Septiembre Sun Microsystems difundió un boletín (boletín
189) en el que se anunciaba la distribución de estos parches. Los
parches se aplican sobre las versiones SunOS 5.6 y 5.7 (Solaris 2.6 y
Solaris 7), tanto en su versión Sparc como Intel. El resto de versiones
Solaris no están afectadas.

Los parches aplicables son:

SunOS version Patch ID
_____________ _________

5.7 106541-07
5.7 ufsrestore 106793-03
5.7 rcp 107972-01

5.7_x86 106542-07
5.7_x86 ufsrestore 106794-03
5.7_x86 rcp 107973-01

5.6 105210-24
5.6 ufsrestore 105722-03
5.6 rcp 107991-01

5.6_x86 105211-22
5.6_x86 ufsrestore 105723-03
5.6_x86 rcp 107992-01

Los parches son públicos y están disponibles para todos los usuarios
Solaris, independientemente de si disponen de un contrato de
mantenimiento o no.

Más información:

Sun Security Bulletin Archive
http://sunsolve.sun.com/pub-cgi/secBulletin.pl

Parches Solaris públicos
ftp://sunsolve.Sun.COM/pub/patches/




Jesús Cea Avión
jcea@argo.es
http://www.argo.es/~jcea/



martes, 28 de septiembre de 1999

Cifrado seguro utilizando una simple baraja de póker

Bruce Schneier ha diseñado un algoritmo de cifrado seguro que emplea
únicamente una baraja de póker de 54 cartas. Se trata de un algoritmo de
cifrado en ristra o flujo ("stream", en inglés), y ha sido diseñado para
que sea sencillo y fácil de realizar a mano, sin apoyo informático. El
algoritmo se llama "solitaire" y fue creado para la novela
Cryptonomicon, de Neal Stephenson, publicada esta primavera.
El algoritmo se basa en mover las cartas del mazo siguiendo una serie de
pasos, y combinar sus resultados con el documento a cifrar. La clave
está constituida por la disposición inicial de las 54 cartas de la
baraja de póker, por lo que su fortaleza aparente es de 54! (54
factorial), aproximadamente 236 bits.

Se dá la curiosa circunstancia de que este algoritmo parece lo bastante
seguro como para que sea considerado como tecnología de doble uso (como
las minas o las balas de ametralladora) por parte del gobierno
estadounidense. Este hecho podría suponer la ilegalidad de exportar el
conocimiento de dicho algoritmo a países extranjeros.

Sin embargo la legislación de EE.UU. protege la libertad de expresión
escrita, por lo que se permitiría la exportación sin problemas si el
algoritmo se describiese en un libro editado de forma legal, con ISBN,
etc. Y eso es precisamente lo que se hace en la novela de Neal
Stephenson, en la que "solitaire" aparece como un apéndice.

Parece increíble que un algoritmo criptográfico tan sencillo, que puede
memorizarse y utilizarse de forma manual, pueda estar sujeto a
legislación militar. Pero la legislación norteamericana es así. En
cualquier caso Bruce Schneier ha tomado la iniciativa y ha decidido
publicar una página web en la que describe con todo detalle el
algoritmo, proporciona ejemplos, consejos de uso, código fuente para los
que deseen utilizarlo con un ordenador y vectores de prueba para
comprobar que las implementaciones son correctas.

El documento original está escrito en inglés, pero Jesús Cea Avión se ha
encargado de traducirlo al castellano y hablar con Bruce Schenier para
que añada enlaces a la traducción. En este momento, además de la versión
en inglés y la versión en castellano recientemente traducida, existen
también traducciones oficiales el francés y al alemán.


Jesús Cea Avión
jcea@argo.es
http://www.argo.es/~jcea/


Más información:

The Solitaire Encryption Algorithm
http://www.counterpane.com/solitaire.html

El Algoritmo de Cifrado "Solitaire"
http://www.argo.es/~jcea/artic/solitaire.htm

lunes, 27 de septiembre de 1999

IP Spoofing en Linux 2.2.x (x<13)

Un error de implementación en los kernel Linux 2.2.x permite una
predicción muy aproximada del número de secuencia inicial de una
conexión TCP/IP. Acertando en dicha predicción, es posible injectar
información aparentemente procedente de una IP diferente a la del
atacante. Si entre la máquina atacada y la IP que se simula existe algún
mecanismo de confianza (especialmente, herramientas r* y NFS) el
atacante puede comprometer la seguridad de la máquina atacada.
El ataque fue publicado el pasado 26 de Septiembre en la lista de
desarrollo del Kernel, y fue seguido por una furiosa actividad para
evaluar su alcance y solucionar el problema en el menor plazo posible.
El error fue introducido en los kernels 2.2.x; los kernel 2.0.x no son
vulnerables.

El problema es doble: por una parte, uno de los secretos utilizados a la
hora de calcular el ISN no es ni secreto ni aleatorio, sino una
constante conocida: cero. En segundo lugar, se utilizan campos como los
números de puerto de la conexión para calcular el ISN, pero no la IP del
remitente, debido a otro bug de programación.

El problema está corregido en la versión 2.2.13pre13. Pero gracias a
disponer del código fuente, no hace falta esperar a la aparición del
kernel 2.2.13 oficial. Cualquiera puede solucionarlo de forma local sin
más que aplicar algunos parches.

Para el primer problema, tenemos:


--- linux.vanilla/drivers/char/random.c Thu Dec 31 20:03:49 1998
+++ linux.13p12/drivers/char/random.c Sun Sep 19 15:00:34 1999
@@ -1698,7 +1698,7 @@
if (!rekey_time || (tv.tv_sec - rekey_time) > REKEY_INTERVAL) {
rekey_time = tv.tv_sec;
/* First three words are overwritten below. */
- get_random_bytes(&secret+3, sizeof(secret)-12);
+ get_random_bytes(&secret[3], sizeof(secret)-12);
count = (tv.tv_sec/REKEY_INTERVAL) << HASH_BITS;
}

Y para el segundo problema, el parche es


--- linux.vanilla/net/ipv4/tcp_ipv4.c Sat Aug 28 20:00:59 1999
+++ linux.13p13/net/ipv4/tcp_ipv4.c Sun Sep 26 23:25:18 1999
@@ -525,7 +525,8 @@

static inline __u32 tcp_v4_init_sequence(struct sock *sk, struct
sk_buff *skb)
{
- return secure_tcp_sequence_number(sk->saddr, sk->daddr,
+ return secure_tcp_sequence_number(skb->nh.iph->daddr,
+ skb->nh.iph->saddr,
skb->h.th->dest,
skb->h.th->source);
}

Una vez más se puede ver como el enfoque "Open Source" ha podido
localizar y corregir un problema en apenas unas pocas horas.

Más información:
TESO
Página web de uno de los descubridores
IP Spoofing Trivial en los Kernel Linux Inferiores a 2.0.36



Jesús Cea Avión
jcea@argo.es
http://www.argo.es/~jcea/



domingo, 26 de septiembre de 1999

"Suppl", el primer i-worm basado en Word

Es posible comprobar cómo, en los últimos meses, la producción
vírica se centra con especial intensidad en dos campos: virus
de macro e i-worms. Este hecho explica la aparición de "Suppl",
un i-worm híbrido basado en la ejecución automática de rutinas
en documentos de Word, de la misma manera que funcionan los
abundantes virus de macro.
De acuerdo con Eugene Kaspersky, de AVP, se trata de un i-worm
de origen ruso o ex-soviético, hecho que se ha podido comprobar
a partir de la versión del Word con la que fue generado el DOC
que sirve de vehículo a "Suppl" y que ha sido enviado a varios
grupos de noticias este mismo mes.

"Suppl" llega a nuestros buzones por medio de e-mails junto a
los que aparece, en forma de fichero adjunto, como "SUPPL.DOC",
de donde se ha tomado su nombre. Cuando este documento es
abierto tiene lugar la ejecución automática de su única macro,
denominada "Document_Open". Por medio de esta macro, "Suppl"
crea una copia del documento, con el nombre "ANTHRAX.INI", en
el directorio de Windows, junto con una DLL contenida en el
fichero DOC infectado y previamente comprimida con el método
LZH.

Modificando el fichero WININIT.INI, el i-worm consigue que sea
el propio Windows el que renombre esta DLL como WSOCK32.dll,
conservando el módulo original como WSOCK33.dll. De este modo,
"Suppl" consigue tener acceso total a los servicios de red, de
manera que podrá monitorizar las actividades necesarias para
así enviarse a otros ordenadores por e-mail.

Al igual que otros i-worms, como "Happy99" o "Fix2001", nuestro
protagonista sólo se interesa por las APIs "connect" y "send",
suficientes para saber cuándo se conecta el propietario de la
máquina infectada a la red y cuándo se están enviando datos a
otros usuarios por correo electrónico, ocasión que aprovecha
"Suppl" para adjuntar un nuevo documento infectado y así cerrar
su ciclo reproductor, que, afortunadamente, no afecta a quienes
trabajen con WindowsNT.

A pesar de que hasta este punto todo parezca estar en orden y
que no hayamos comentado ninguna característica que lo hiciese
de una manera u otra especial con respecto a los i-worms que
conocemos por ahora, "Suppl" tiene una sorpresa preparada para
los usuarios afectados, y es que, antes de despedirse de una
máquina infectada, este i-worm borra todos los ficheros con
extensión ARJ, DBF, DOC, RAR, RTF, TXT, XLS y ZIP de aquellos
ordenadores accesibles, ya sea de manera local o remota. Si
bien se trata de una activación similar a la que hemos visto
en el i-worm "ZippedFiles", es necesario hacer eco del peligro
que entraña para aquellos usuarios afectados por "Suppl" en un
plazo inferior a siete días, ya que aún se encuentran a tiempo
de salvar su información por medio de software antivirus.

Más información:
AVPVE
DataFellows
NAi
Sophos
Symantec
Trend



Giorgio Talvanti



sábado, 25 de septiembre de 1999

Problemas de Eudora con el plug-in PGP

El problema afecta al cliente de correo Eudora en sus versiones 3.x,
disponibles para Windows 95/98 y NT, que utilicen el plug-in de PGP
proporcionado por NAi y tengan activada la opción del corrector
ortográfico.
El conflicto surge por la secuencia que Eudora sigue a la hora de
utilizar el plug-in y el corrector antes de enviar un mensaje. En
primer lugar invoca a PGP para realizar la firma sobre el texto,
a continuación, y una vez que termina su función el plug-in, se
llama al corrector ortográfico.

Esta forma de actuación puede provocar que se hagan modificaciones
sobre el texto, la corrección de alguna palabra por ejemplo, con lo
que la firma realizada con anterioridad por PGP queda invalidada.
La secuencia correcta sería realizar primero todas las correcciones
sobre el texto y dejar como último paso, antes del envío, la
llamada al plug-in PGP.

La solución a este problema pasa por desactivar la revisión
ortográfica automática, y llamar a esta función de forma manual para
llevar a cabo las modificaciones antes de realizar la firma PGP. Las
versiones 4.x de Eudora se encuentran libres de este fallo.

Más información:
Aviso en Attrition
Descripción gráfica
PGP - Network Associates



Antonio Román



viernes, 24 de septiembre de 1999

Parches "Y2K" fraudulentos

Al igual que en la Edad Media miles de malhechores aprovechaban
el temor de la gente a la llegada del milenio, como aquéllos que
asaltaban por el Camino de Santiago a los peregrinos que acudían
a la capital gallega para expiar sus faltas y así tener su alma
limpia el día del juicio final, a las puertas de la llegada de
un nuevo milenio estamos presenciando un proceso similar, de la
mano de los escritores de virus.
Si bien es cierto que el nuevo milenio no empieza hasta el día
1 de enero del 2001, ya que no existió el año 0, parece que ya
resulta imposible convencer al gran porcentaje de la población
mundial que recibe el nuevo año con gran euforia pensando que
se trata de la llegada de un nuevo siglo... y milenio, de forma
análoga al proceso que se vivió en Europa ante la llegada del
año 1000. Y de la misma manera, salvando las diferencias, vemos
cómo son ahora los escritores de virus los encargados de cometer
ciertas fechorías, aprovechándose de la confusión de la gente.

Mientras que en la Edad Media se trató de la creencia de que se
acercaba el fin del mundo, actualmente el problema del milenio
se centra en la actualización de aquellos sistemas que no son
compatibles con una numeración anual de cuatro dígitos, cuestión
que lleva dando mucho que hablar, con especial intensidad, como
es lógico, en los últimos meses. Sea lo que sea, la confusión
vuelve a reinar, mil años después.

Hay quienes se han dado prisa y, aprovechando el auge de la
difusión de los llamados parches "Y2K", han camuflado código
maligno de distinta índole con el fin de expandir su creación
a lo largo de Internet. Los casos más recientes, y casi por
consiguiente los más sonados, son "Fix2001" y "Count2K", un
i-worm y un caballo de Troya respectivamente, que han saltado
en pocos días a las secciones de alerta de la mayoría de las
compañías antivirus de mayor relevancia a nivel internacional.

El primero es un i-worm de características muy similares al ya
famoso "Happy99": llega a nuestros buzones en forma de "attach",
acompañando a un mensaje en inglés y en español, presuntamente
proviniente de Microsoft, y una vez ejecutado crea un "dropper"
en el directorio de Windows para ejecutarse en cada arranque de
la máquina, tras haber modificado el registro del sistema y
mostrar al usuario un mensaje falso, haciéndole creer que su
sistema no necesita ser actualizado para la llegada del 2000. A
partir de este punto, el i-worm engancha las funciones "connect"
y "send" del módulo WSOCK32.dll, por medio de las cuales, una
vez que el usuario se ha conectado a Internet, intercepta los
datos recibidos y se envía por e-mail a las cuentas de correo
procesadas durante la conexión. La desinfección de este i-worm,
de procedencia aparentemente argentina, ha de ser muy cautelosa,
ya que "Fix2001" chequea su integridad y, en caso de detectar
alguna anomalía, procede a sobreescribir COMMAND.COM con un
troyano que, en el siguiente arranque, borrará todos los datos
de la unidad activa.

El troyano "Count2K" no es menos peligroso, si bien no borra
información del disco duro. El efecto es el contrario, ya que
el propósito de este troyano es, como el de otros, robar los
datos de conexión a Internet del usuario afectado. Este agente
infeccioso se expande por medio de un e-mail, nuevamente en
teoría enviado por Microsoft, en forma de fichero adjunto, de
un tamaño sensiblemente superior al de "Fix2001" (120k frente
a 12k). Una vez ejecutado, el troyano muestra un mensaje de
error de CRC mientras se autoexpande en un EXE y cinco DATs,
que rápidamente cambian de nombre, extensión y ubicación, para
trasladarse directos a la carpeta de Windows y sustituír al
conocido módulo WSOCK32.dll. El troyano se instala añadiendo
uno de sus ficheros al WIN.INI como "driver" del sistema, de
manera que en el siguiente arranque estará activo y listo para
monitorizar cualquier conexión a Internet y enviar los datos
de acceso a Internet (RAS) del usuario a su autor.

En HispaSec estamos seguros de que estos dos especímenes son
probablemente los primeros, pero no serán los últimos... aún
quedan más de tres meses para la llegada del 2000, y lo único
que cabe pensar es que lo peor está por venir. Desde nuestro
laboratorio, la recomendación más básica que podemos difundir
entre nuestros lectores es tan simple como no ejecutar por
norma ninguna aplicación adjunta a e-mails, a no ser que se
haya solicitado explícitamente de algún conocido, y siempre
manteniendo especial atención a todo lo que presuntamente nos
llegue por parte de Microsoft.

Más información:
AVPVE
Network Associates (Count2K)
Network Associates (Fix2001)



Giorgio Talvanti



jueves, 23 de septiembre de 1999

La vulnerabilidad de Hotmail común en los webmail

En el último mes la polémica a causa de las continuas
vulnerabilidades ha rodeado a Hotmail, el servicio de mail
gratuito a través de web más usado de todo Internet, pero los
problemas de Hotmail son comunes en otros servicios similares.
La última vulnerabilidad descubierta por el conocido programador
Georgi Guninski ha provocado la alarma generalizada dentro de
Internet, ya que todo parece indicar que la gran mayoría de
sitios de mail por web poseen problemas de seguridad similares.
La vulnerabilidad de Hotmail se basaba en la posibilidad de
inyectar y ejecutar código JavaScript dentro de un mensaje de
e-mail mediante el uso de tags. Este ataque puede reproducirse
con facilidad en muchos otros servidores dejando a la luz de un
posible ataque a los logins y passwords de los usuarios.

Si a esto le unimos que la gran mayoría de los usuarios emplean
las mismas contraseñas y nombres de usuario para diferentes
sitios en Internet la utilización de estos servicios se convierte
en una práctica peligrosa. Según el experto Richard M.Smith,
consultor de seguridad independiente en Cambridge, el problema
consiste en que conseguir atajar totalmente los bugs en este tipo
de sitios webs es prácticamente imposible debido a la gran
cantidad de variables propias del servicio que prestan.

En la actualidad todos los programadores de estos servicios
intentan dar solución a algunos de estros problemas impidiendo la
entrada de mensajes con código JavaScript insertado en los
e-mails entrantes, con lo que impediría en una posterior
ejecución la infección, pudiendo dejar a sus usuarios protegidos
ante estos ataques. El problema surge en ataques como el último
descubierto por Guninski basados en camuflar las instrucciones
Javascript dentro de tags permitidos.

Más información:
Internetnews
HispaSec
HispaSec
Georgi Guninski



Antonio Román



miércoles, 22 de septiembre de 1999

Una utilidad de Compaq borra el "aviso legal" en NT

Durante el proceso de instalación de "Compaq Integration
Maintenance Utility" se borra el contenido de la clave del
registro destinada a mostrar los avisos legales de inicio de
sesión en Windows NT.
En la segunda entrega sobre la configuración segura del registro
en Windows NT, "una-al-dia" del 4/7/1999, hablabamos, entre
otras recomendaciones, sobre la clave del registro que nos
permitía introducir avisos legales o cualquier otra información
en los inicio de sesión.

Ruta: HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon
Variables: LegalNoticeCaption y LegalNoticeText

La cadena de texto que introduzcamos en "LegalNoticeCaption" se
visualizará en la barra de título de la ventana cada vez que el
usuario presione CTRL+ALT+SUPR durante el inicio de sesión. Con
"LegalNoticeText" podremos ampliar nuestros avisos, consejos,
o normas internas, que puedan prevenir de un mal uso de la red
y reprimir intentos de sabotajes.

En el proceso de instalación de "Compaq Integration Maintenance
Utility" se sobrescribe el contenido de "LegalNoticeText" para
que se visualice un mensaje indicando que la instalación continua
después de reiniciar. Una vez que ha terminado todo el proceso,
la utilidad de Compaq borra el contenido de "LegalNoticeText" y
no restaura su valor original.

Compaq ha confirmado el problema y asegura que estará corregido
en la versión 4.50 de SmartStart, disponible a primeros de
noviembre de este año.

Más información:
HispaSec:
http://www.hispasec.com/unaaldia.asp?id=251
NTBugtraq:
http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind9909&L=ntbugtraq&F=&S=&P=314
NTBugtraq:
http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind9909&L=ntbugtraq&F=&S=&P=3434



Bernardo Quintero



martes, 21 de septiembre de 1999

Un análisis del dispositivo de factorización de Shamir

La compañía RSA hace público un documento analizando el dispositivo
TWINKLE, diseñado por Adi Shamir. Este dispositivo permitiría acelerar
una de las dos etapas necesarias para factorizar un número, en tres
órdenes de magnitud (unas mil veces más rápido).
Como ya se comentaba en el boletín enviado el pasado 2 de Septiembre,
los algoritmos actuales de factorización se basan en dos etapas: en la
primera varios ordenadores buscan, en paralelo, una serie de relaciones
de congruencia. En una segunda etapa, un superordenador con una gran
cantidad de memoria procede a resolver la ecuación matricial obtenida en
el paso anterior.

El dispositivo de Shamir, llamada TWINKLE, permite acelerar unas mil
veces la primera etapa, aunque no aporta ninguna mejora adicional a la
segunda etapa.

En el documento que comentamos en este boletín, uno de los
investigadores de RSA realiza un análisis detallado de las implicaciones
prácticas de dicho dispositivo.

El primer paso consiste en evaluar cuánto se hubiera tardado en
factorizar RSA-140 (el mayor reto RSA factorizado en aquel momento;
recientemente se ha factorizado el RSA-155).

Para igualar las características de los equipos empleados en el reto
RSA-140, hubieran bastado sólo 7 dispositivos TWINKLE. Toda la primera
etapa de criba hubiera podido completarse en 6 días, en vez de las
cuatro semanas y 200 ordenadores utilizados realmente. La segunda etapa,
la resolución de la ecuación matricial, seguiría necesitando 100 horas
de cálculo en un superordenador. Se hubiera pasado de 33 días a 10 días.
Incluso con una criba infinitamente rápida, el tiempo requerido para
completar la segunda etapa hubiera sido de unas 100 horas. La ganancia
óptima no hubiera superado un factor del 800%.

RSA-140 tiene 465 bits. A medida que crece el tamaño de los números a
factorizar, aumenta el tiempo de criba, y el tamaño y tiempo para
resolver la ecuación matricial final. Operación, ésta última, que no se
puede paralelizar fácilmente.

Como comparación, factorizar RSA-140 (465 bits) consumió 64Mbytes de RAM
en cada una de las máquinas que colaboraron en la criba, y 825 Mbytes en
el superordenador. Factorizar un número de 768 bits supondrá 10Gigabytes
en cada ordenador que cribe y 160Gbytes en el superordenador. Factorizar
un número de 1024 bits necesitaría 256Gbytes en cada máquina de criba, y
10TeraBytes en el superordenador.

Se puede ver una estimación de tiempos para cada tamaño de número en
http://www.argo.es/~jcea/artic/hispasec08.htm.

A la vista de estos datos, es razonable pensar que las claves RSA de 768
bits son seguras a medio plazo, y las claves de 1024 bits están fuera de
las posibilidades de nada que podamos imaginarnos en este momento
tecnológico.

Más información:

An Analysis of Shamir's Factoring Device
An Analysis of Shamir's Factoring Device (PDF)
Nuevo dispositivo óptico para factorizar más rápido (jcea)
Nuevo dispositivo óptico para factorizar más rápido (HispaSec)
Factorización de RSA-155 (jcea)
Factorización de RSA-155 (HispaSec)



Jesús Cea Avión
jcea@argo.es
http://www.argo.es/~jcea/



lunes, 20 de septiembre de 1999

Un nuevo agujero en Hotmail

De nuevo Georgi Guninski, de nuevo Hotmail y de nuevo un agujero
que permite inyectar y ejecutar código Javascript en un mensaje
e-mail a los usuarios del popular servicio de mensajería.
Hotmail vuelve a ser vulnerable y una vez más Georgi Guninski es
el descubridor del nuevo fallo. El exploit funciona tanto en
Internet Explorer 5.0 como en Netscape Communicator 4.x. Como ya
comentamos anteriormente Hotmail establece filtros para evitar
que se incluya código Javascript en los mensajes y se produzcan
ataques empleando dicho lenguaje.

Pero los filtros establecidos por Hotmail parece que no son
suficientes, una vez más empleando un simple truco se puede
evitar dicha protección. El dispositivo no controla de forma
eficaz la cadena "javasCript:" donde "C" es el código ASCII
de la "C". De esta forma se puede lograr ejecutar el siguiente
código html:
<IMG SRC="javasCript:alert('JavaScript se ejecuta');">.

Ejecutar el código Javascript cuando el usuario abre el mensaje
puede permitir mostrar una falsa ventana de conexión, en la que
el usuario introduzca su contraseña que será enviada al atacante.
También puede permitir leer los mensajes del usuario, enviar
mensajes a nombre del usuario atacado, etc.

Un ejemplo de las posibilidades de esta vulnerabilidad se muestra
en el siguiente código:
<IMG SRC="javasCript:alert('JavaScript se
ejecuta');a=window.open(document.links[2]);setTimeout('alert(\'El
primer mensaje en su buzón es de :
\'+a.document.links[26].text)',20000)">

Más información:
Georgi Guninski
BugTraq



Antonio Ropero



domingo, 19 de septiembre de 1999

Cientos de sitios web afectados por una vulnerabilidad en WWWBoard

Una vulnerabilidad en "WWWBoard" permite acceder a las
contraseñas de los administradores de estos foros a
través de una sencilla URL. A pesar de que este fallo ha
saltado a la luz en distintas listas de seguridad, hemos
podido comprobar como a día de hoy la gran mayoría de los
sitios siguen vulnerables.
"WWWBoard" es un script en perl, desarrollado por Matthew M.
Wright, que permite la creación de foros de discusión en
páginas web (http://www.worldwidemart.com/scripts/wwwboard.shtml).
Para la administración del foro se utiliza la autentificación
mediante un nombre de usuario y su correspondiente contraseña.
Por defecto "WWWBoard" trae como nombre de usuario "WebAdmin"
y la contraseña "WebBoard".

Aquí ya encontramos el primer fallo, aunque el programa
recomienda el cambio de contraseña nada más entrar, sería más
conveniente que forzara a introducir al administrador un nombre
de usuario y contraseña en vez de proporcionar éstas por
defecto.

Pero esto no deja de ser una anécdota, ya que el principal
problema surge cuando, siguiendo las recomendaciones, optamos
por introducir un nuevo nombre de usuario y contraseña. Por
defecto, "WWWBoard" almacena la información de la cuenta en
el fichero "passwd.txt" con la contraseña cifrada utilizando
la función Unix crypt(3) que utiliza una variación del DES.
Hasta aquí todo correcto, si no fuera porque este fichero es
accesible desde un simple navegador con una sencilla URL tipo:
http://www.servidor.com/wwwboard/passwd.txt

Una vez accesible la cuenta del administrador del foro, en una
línea tipo [usuario]:[contraseñacifrada], el descubrir la
contraseña está al alcance de cualquiera y sólo depende de la
pericia del atacante y la calidad de la contraseña. Basta
contar con algunas de las múltiples utilidades a tal efecto y
un buen diccionario de posibles contraseñas.

La solución para los administradores se presenta trivial, basta
con mover el fichero a otro directorio no accesible desde web,
renombrarlo si se quiere, y modificar la línea: [$passwd_file =
"passwd.txt";] para que apunte a la nueva ubicación.

Recordemos que la función crypt de Unix utiliza la cadena que se
pasa de parámetro como clave para realizar el cifrado de un
bloque de 64 bits puestos a cero, y repite la operación 25 veces
volviendo a cifrar el resultado. Este proceso nos da 64 bits que
se representan con 11 caracteres, a los que hay que sumar lo que
se conoce como "salt", que es un número de 12 bits que proviene
del reloj del sistema, utilizado durante el proceso de cifrado.
La "salt" es representada por dos caracteres, y se sitúa delante
de la contraseña cifrada, con lo que el resultado final será una
cadena de 13 caracteres, como por ejemplo: "GiBzoWz4Y6E1A".

En teoría no existe forma de poder invertir el algoritmo de
cifrado. Para poder descubrir una contraseña cifrada con esta
función, lo que se hace es comparar el resultado de cifrar
posibles contraseñas con la contraseña cifrada que queremos
descubrir. Si el resultado coincide, se habrá alcanzado el
objetivo. Para realizar esta operación existen utilidades
creadas a tal efecto, que ejecutan a gran velocidad las
operaciones, a partir de las posibles contraseñas de diccionarios
de palabras y/o haciendo múltiples combinaciones.

Más información:
WWWBoard
Bugtraq



Bernardo Quintero



sábado, 18 de septiembre de 1999

Instalación insegura de Service Pack 5

La instalación del Service Pack 5, en determinadas condiciones,
puede permitir la ejecución de troyanos con privilegios de
"Administrador" a cualquier usuario del sistema.
Durante la aplicación del Service Pack 5, en una estación de
trabajo, la instalación se lleva a cabo bajo el contexto de que
la sesión pertenece a un usuario con privilegios de
"Administrador". En este proceso, y como parte de la instalación,
Service Pack 5 realiza entradas en la clave del registro
"RunOnce", de forma que los programas que en ella se indiquen
serán ejecutados una sola vez, y de forma automática, la próxima
vez que se inicie el sistema. Este forma de actuación no está
recogida en la documentación que Microsoft proporciona con el
SP5.

En grandes entornos corporativos, los administradores pueden
optar por ir de máquina en máquina instalando el SP5 o hacerlo
de forma distribuida con algún sistema como SMS. En cualquier
caso, los administradores no tienen conocimiento de que, después
de aplicar SP5, deben reiniciar el sistema con una sesión con
privilegios de "Administrador" para que los programas, a los que
hace referencia la clave del registro "RunOnce", se ejecuten
bajo las condiciones apropiadas.

En este contexto, cuando los usuarios del puesto de trabajo
inicien el sistema después de que se haya aplicado el SP5 por
parte del administrador, "RunOnce" intentará lanzar los programas
a los que hace referencia. En la mayoría de las ocasiones, la
sesión iniciada por los usuarios no tendrá privilegios de
"Administrador", por lo que el programa lanzado no podrá llevar a
cabo su tarea. Como efecto colateral, la entrada de la clave
"RunOnce" no será borrada, por lo que el programa se ejecutará
cada vez que se inicie el sistema, hasta que la sesión pertenezca
a un usuario con privilegios de "Administrador".

Aprovechando esta situación, cualquiera puede remplazar los
ejecutables a los que se hace referencia en "RunOnce",
PSTORES.EXE y CSVROOT.EXE, ya que los permisos de estos archivos
conceden ese privilegio a cualquier usuario del sistema. Los
nuevos programas se intentarían lanzar en cada inicio de sesión,
al igual que los originales, hasta que se ejecuten bajo el
contexto de una sesión de "Administrador". A partir de aquí se
pueden llevar a cabo multitud de ataques, ya que da carta blanca
para que un troyano se ejecute con acceso total al sistema.

Más información:
NTBugtraq



Bernardo Quintero



viernes, 17 de septiembre de 1999

Máquinas con fallos archiconocidos pueblan el ciberespacio

Añadiendo una simple instrucción a la dirección de una página web, es
posible hacerse con el fichero de contraseñas del ordenador que la
contiene. El fallo, llamado del 'phf' y conocido desde hace años, aún
no ha sido reparado en al menos 7.000 máquinas conectadas a la red.
Ésta es sólo una muestra del escenario de seguridad informática que
pinta el recientemente presentado Internet Auditing Project.
"Nos sorprendió descubrir cuantas redes que esperábamos que fuesen
ultra seguras estaban totalmente abiertas al ataque. Bancos, lugares
comerciales de billones de dólares, compañías de seguridad
informática, incluso centros de investigación en armamento nuclear",
asegura Liraz Siri, portavoz del Internet Auditing Project. Las
últimas tres semanas de 1998, ocho ordenadores en Israel, México,
Rusia, Brasil y Japón escanearon entre todos 36 millones de "hosts" de
Internet, buscando en ellos 18 vulnerabilidades que permiten el acceso
máximo a sistemas Unix. Analizados los datos obtenidos, se vio que por
lo menos 450.000 máquinas presentaban fallos, debidos a malas
configuraciones o al uso de versiones demasiado antiguas de los
programas, tan viejos y documentados como el fallo del "rpc_mountd",
conocido desde 1994.

En un mensaje de 24 páginas al foro de discusión de Securityfocus, el
grupo hacía públicos parcialmente los resultados del sondeo, así como
el código fuente del Bulk Auditing Security Scanner, el programa que
escribieron para la macroauditoría. En el mensaje, fechado el 11 de
agosto, destacan haber recibido desde educadas cartas de los
administradores de sistemas escaneados hasta demandas de abogados y
algún ataque directo: "Sabíamos que mucha gente se pone nerviosa si se
la somete a una auditoría de seguridad sin avisarles. En algunos
países, eres considerado un criminal sólo por eso. La legislación
sobre "crimen informático" es absurda. Las leyes tratan de proteger
los sistemas informáticos del mal uso, cuando la única forma de
prevenir el abuso es escribir un mejor código (de los programas)".

El Internet Auditing Project no es la primera auditoría de seguridad
que se ha hecho a la red, aunque sí la más publicitada en los últimos
tiempos y de las pocas realizadas por un grupo independiente. "Hace
unos años - cuenta Hal Lockhart en el foro de Securityfocus - Dan
Farmer hizo un escaneo, no tan exhaustivo, donde se vio que el 40% de
los ordenadores de la red podían ser crackeados trivialmente y otro
20%, con poco trabajo". El grupo ha aprovechado la difusión de su
hazaña para proponer la creación de una International Digital Defense
Network con la que, al estilo de Distributed.net, ordenadores
trabajando en paralelo velarían por la seguridad de Internet.

Internet Auditing Project
-------------------------

Nodos de escaneo: 5
Trabajos Por Minuto: 250
Tiempo de escaneo: 20.24 días

Vulnerabilidades testadas: 18

Dominios: 7 dominios de tres letras, 214 dominios nacionales
Máquinas: 36.431.374
Vulnerabilidad: 730.213
Máquinas vulnerables: 450.000

Servicio Vulnerabilidad %

tooltalk 190.585 máquinas 26.1%
(servidor de bases de datos. Avisado por el CERT en 1998)

bind 132.168 máquinas 18.1%
(Berkeley Internet Name Daemon. Avisado por el CERT en 1996)

wu_imapd 113.183 máquinas 15.5%
(Internet Message Access Protocol, programa de correo. Conocido por el CERT desde 1997)

qpopper 90.546 máquinas 12.4%
(servidor de correo POP. Avisado por el CERT en 1998)

wwwcount 86.165 máquinas 11.8%
(contador de web)

rpc_mountd 78.863 máquinas 10.8%
(servidor para montar particiones de red, en SunOS. Conocidas vulnerabilidades desde 1994)

ews 9.346 máquinas 1.28%
(Excite Web Server, programa buscador. Avisado por Excite en 1998)

phf 6.790 máquinas 0.93%
(extensor de páginas web)

webdist 5.622 máquinas 0,77%
(programa cgi para IRIX. Avisado por el CERT en 1997)

innd 3.797 máquinas 0,52%
(InterNet News Daemon. Avisado por el CERT en 1997)

Otras vulnerabilidades 18.000 máquinas 2.42%

Más información:
Ciberp@ís
Internet Auditing
Netscan.org
The Internet Operating System Counter



Mercè Molist



jueves, 16 de septiembre de 1999

Vulnerabilidad en Compaq Management Agents

El equipo de seguridad de Compaq da a conocer una vulnerabilidad
que se genera durante la instalación de "Compaq Management
Agents" para servidores Windows NT.
En el aviso, publicado en Bugtraq y posteriormente es su sitio
Web, indica que el agujero se deriva de la creación, sin avisar
al administrador, de una cuenta con elevados derechos en el
sistema. El principal problema, como veremos al final de la noticia,
viene dado por la creación automática de la contraseña.

Durante la instalación de la versión 4.20D de la herramienta de
administración "Compaq Managament Agents" se crea en el sistema,
sin notificar en ningún momento al usuario, la cuenta "PCFUser".
Esta cuenta es configurada con altos privilegios, y forma parte
del grupo de "Administradores". Compaq ha confirmado que hay
vulnerabilidades que afectan a esta cuenta:

1) La cuenta "PCFUser" es vulnerable debido a la creación
automática de la contraseña.
2) En ningún momento se notifica de la creación de esta cuenta al
usuario.
3) La cuenta tiene elevados derechos en el sistema.
4) Incertidumbre en el proceso de desinstalación.

Compaq recomienda que se cambie la contraseña para la cuenta
"PCFUser" usando la utilidad "PFIMuser" que se facilita durante
la instalación de "Compaq Managament Agents". El aviso hace
hincapié en la necesidad de utilizar esta utilidad,
"PFMIUSER.EXE", en vez del Administrador de Usuarios para
Dominios de Windows NT.
Los pasos a seguir son:

1) Iniciar una sesión como Administrador
2) Abrir una ventana DOS
3) Cambiar de directorio: CD /Winnt/System32/pfc
4) Lanzar la utilidad "PFIMuser": pfmiuser.exe
5) Teclear el nombre de usuario cuando lo solicite: PFCUser
6) Teclear la nueva contraseña
7) Confirmar la nueva contraseña

En el mismo aviso, Compaq también explica con detalle como
desinstalar los componentes necesarios para anular la cuenta
PFCUser. Por último, anuncia la salida de "Compaq Foundation
Agents 4.40B" que estará disponible a finales de septiembre.
Entre las novedades que incorporará se encuentra el aviso al
usuario de la creación de la cuenta, así como la solicitud de la
contraseña.

El problema real, que no se hace público en el aviso de Compaq,
parte en el proceso de creación automático de la contraseña
asignada a la cuenta de usuario "PCFUSer". El grave error
consiste en que la contraseña no es única para cada instalación.
Es decir, alguien puede aprovechar este hecho para atacar dicha
cuenta en un sistema al que tuviera acceso. Utilidades como
"L0pthCrack" darían con la contraseña en apenas unas horas, la
cual se puede utilizar a posteriori para autentificarse ante
cualquier Windows NT que tuvieran la cuenta PCFUser con la
contraseña por defecto, obteniendo el control total sobre el
sistema.

Más información:
Compaq



Bernardo Quintero



miércoles, 15 de septiembre de 1999

Sobre puertas y ratoneras

Ya es un viejo tópico afirmar que el comercio electrónico no termina
de despegar. ¿Razones? Variadas y de distinto peso, pero siempre se
esgrime aquella de la seguridad y el temor al fraude. Conscientes de
ello, los administradores web y diseñadores de aplicaciones dedican
sus esfuerzos y sus noches desveladas a fortificar los servidores,
crear sistemas de comercio a prueba de balas y rodear en definitiva a
los portales de venta de una sólida atmósfera de confianza, que
induzca al cliente potencial a realizar sus compras y gastar su
dinero.
Por supuesto, el problema de fondo no es sólo el prestar una imagen de
seguridad, ya que también está en juego la información privada de los
usuarios y de la propia compañía. Se trata de asegurar todas las
posibles vías de ataque para prevenir la filtración de información,
evitar ataques de denegación de servicio o la modificación de ficheros
en servidores de la compañía, incluyendo su página principal que
constituye su escaparate de cara al mundo y cuya alteración atentaría
seriamente contra su imagen tan arduamente buscada.

Con el fin de lograr estos objetivos de seguridad se contratan
expertos en redes, se instalan cortafuegos que sólo permiten el
tráfico HTTP, se crean políticas de seguridad para toda la empresa, a
menudo se contrata una auditoría externa, para finalmente sentirse
satisfecho con la seguridad global de la aplicación de comercio
electrónico desarrollada. No hay servicios de comunicaciones inútiles
a la escucha, se han utilizado las últimas versiones de los programas
de bases de datos con todos los parches de última hora correctamente
aplicados, todos los permisos están cuidadosamente controlados, las
listas de control de acceso están protegidas, los logs registran cada
movimiento sospechoso, los antivirus están actualizados al minuto, en
definitiva, todas las puertas traseras y ratoneras están cerradas.
Pero, ¿y la puerta principal? ¿No se habrá quedado abierta una
rendija?

Aunque parezca mentira, muchos ataques se producen por la puerta
grande, explotando errores tan obvios que ni los expertos de seguridad
pensaban que existieran o no miraron allí. Se trata de olvidos o
descuidos en la programación en HTML, JavaScript, CGI o ASP.

Muchos autores de programas CGI no son conscientes de que el programa
que escriben se ejecutará en un servidor web, al que accederá
cualquier persona, introduciendo cualquier entrada, incluso las
insospechadas, para las que el programa no está preparado. El no tener
la seguridad en mente a la hora de escribir un programa CGI puede
tener consecuencias desastrosas, pero ¿cuántos programadores están
preparados para el reto? Un descuido puede permitir a un atacante
desde husmear el contenido de archivos del servidor, hasta ganar
acceso de root al sistema. Dentro del capítulo de CGI, se puede
incluir a los server side includes (SSI), que permiten toda clase de
trucos para llegar a ejecutar comandos arbitrarios o listar el
contenido de ficheros seleccionados. Se puede encontrar información
completa sobre este tipo de ataques en
www.iec.csic.es/criptonomicon/cgi, tema que ya ha sido tratado en
profundidad.

Por otro lado, los formularios en páginas web, tal vez debido a su
sencillez de programación en HTML, resultan muy descuidados. Es común
que no se comprueben las longitudes de las entradas de los usuarios,
que a veces, deliberadamente o no, serán inusualmente largas,
provocando un fallo del programa que debe procesarlas. En el caso
peor, se podría producir una caída del servicio, mientras que en otros
casos se puede revelar indeseadamente el nombre de algún programa o
fichero de datos, información sobre la estructura de directorio del
servidor, software utilizado, y otros datos parecidos, valiosos en
manos de un atacante.

Otros errores comunes consisten en la utilización de campos ocultos en
formularios para asignar el valor a ciertas variables, como por
ejemplo el precio de un producto. La manipulación del formulario y de
dicha etiqueta resulta trivial usando cualquier editor de texto,
permitiendo que cualquier atacante pueda modificar a voluntad el valor
de estos campos. Se puede encontrar un ejemplo tal en
www.iec.csic.es/criptonomicon/cookies/tienda.html. Si no existe una
programación en el servidor que contraste los datos enviados desde el
formulario, la tienda virtual puede experimentar grandes pérdidas.

Los URL también pueden explotarse para obtener información acerca de
otros usuarios. A menudo, los programadores creen que una página sólo
será accedida desde otra página anterior o un formulario. Pero un
atacante podría crear un URL, escribiéndolo directamente en la ventana
de dirección, e intentar acceder a algún recurso protegido, como los
datos de clientes o bases de datos confidenciales, saltándose los
filtros del programador, que se encontraban en la página anterior.

Nuevos ataques están proviniendo de la utilización de etiquetas en
JavaScript, que se incluyen en ventanas que se presentan al cliente en
un formulario para que introduzca un texto, como su opinión acerca de
un producto o la descripción de las características de un cierto
artículo. El usuario medio introducirá texto sencillo, mientras que el
avezado intentará introducir incluso programas en JavaScript, que a
veces pueden llegar a ejecutarse en la página web del comercio cuando
la visite el siguiente cliente. Un truco común en este caso es la
petición al siguiente usuario de su login y password, que confiado los
introduce sin reservas, pasando así a ser conocidos por el atacante.

En resumen, existe toda una serie de ataques ingeniosos basados
exclusivamente en la web, que no hacen uso de sofisticadas
herramientas de hacking, ni requieren grandes recursos
computacionales, ni explotan características de protocolos de difícil
conocimiento. Utilizan la puerta grande. Se llevan a cabo rellenando
formularios y escribiendo los URL de manera ingeniosa. La única
herramienta que precisan es un navegador. Por lo tanto, pasan a través
de todos los controles estándar de filtrado de paquetes y de control
de contenido, al ser ataques disfrazados tras el tráfico web
convencional.

Cuando se diseña una aplicación web sofisticada también deben tenerse
en cuenta estos agujeros, aunque se hayan cerrado todas las otras
pequeñas puertas traseras. Recuerde, de nada le sirve tapar las
ratoneras si se deja abierta la puerta principal.




Gonzalo Álvarez Marañón
criptonomicon@iec.csic.es
Boletín Criptonomicón #55
http://www.iec.csic.es/criptonomicon



martes, 14 de septiembre de 1999

Factorización de RSA-155

Un equipo de personas de todo el mundo, con casi 300 ordenadores,
consigue completar la factorización RSA-155 en poco más de 5 meses.
Este resultado demuestra de forma patente, una vez más, que las
claves públicas RSA de 512 bits no suponen un obstáculo frente a
cualquier organización de medianas proporciones.
El pasado 26 de Agosto (aunque la fecha real del hito fue el día 22),
RSA hizo pública una nota de prensa en la que anunciaba que su reto
RSA-155 había caído, fruto del esfuerzo conjunto de un equipo
multinacional y sus 8000 MIPS-año. Dado que 155 dígitos decimales
suponen unos 515 dígitos binarios, y la mayoría de las soluciones de
comercio electrónico y navegadores web implementan sólo claves de 512
bits, está claro que cualquiera de las claves comúnmente empleadas en
Internet con fines comerciales es susceptible de ataque. Este tipo de
claves son empleados, por ejemplo, para la emisión de certificados,
empleados en S/MIME y SSL (HTTPS).

Lamentablemente la legislación actual norteamericana no permite exportar
al extranjero productos con claves RSA de longitud superior a los 512
bits, a pesar de que todos los expertos coinciden en que se requieren
claves de 768 bits (unos 231 dígitos decimales) para poder disfrutar de
una seguridad mínimamente confortable.

Algunos datos de interés:

El número a factorizar era

RSA-155 =
1094173864157052742180970732204035761200373294544920599091384213147634\
9984288934784717997257891267332497625752899781833797076537244027146743\
531593354333897

que puede escribirse como el producto de dos números primos de 78 cifras:

102639592829741105772054196573991675900716567808038066803341933521790\
711307779
*
106603488380168454820927220360012878679207958575989291522270608237193\
062808643

Se puede obtener más información sobre el tiempo necesario
-aproximadamente- para factorizar un número, en función de su número de
dígitos, en http://www.argo.es/~jcea/artic/hispasec08.htm.

El tiempo estimado de CPU fue de 8000 MIPS-año. El reto RSA-140,
resuelto en Febrero de este año, fue tasado en unos 2000 MIPS-año. Según
la fórmula mostrada en la URL anterior, RSA-155 hubiera requerido
12000-14000 MIPS-año; la diferencia es debida a una mejor selección de
los polinomios generadores, mecanismo también descrito en la URL
proporcionada.

Pueden leerse todos los detalles, en inglés, en
http://www.argo.es/~jcea/artic/hispasec09-2.txt

Más Información:

Para recibir por email la lista de números pendientes de factorizar, hay
que enviar un mensaje a "challenge-rsa-list@rsa.com".

Para recibir por email la lista de números factorizados, por quien, etc,
hay que enviar un mensaje a "challenge-honor-rolls@rsa.com".

Informe Oficial:
http://www.rsasecurity.com/rsalabs/factoring/rsa155.html

Preguntas frecuentes sobre RSA-155
http://www.rsasecurity.com/rsalabs/challenges/factoring/rsa155_faq.html

Nota de prensa oficial:
http://www.rsa.com/pressbox/html/990826.html

Factorización RSA-140:
http://www.rsasecurity.com/rsalabs/factoring/rsa140.html

Retos RSA:
http://www.rsasecurity.com/rsalabs/challenges/

RSA Factoring Challenge:
http://www.rsasecurity.com/rsalabs/challenges/factoring/

Factorization of a 512-bits RSA key using the Number Field Sieve:
http://www.argo.es/~jcea/artic/hispasec09-2.txt

Nuevo dispositivo óptico para factorizar más rápido:
http://www.argo.es/~jcea/artic/hispasec08.htm




Jesús Cea Avión
jcea@argo.es
http://www.argo.es/~jcea



lunes, 13 de septiembre de 1999

Ataque DoS a IE5 con instrucciones HTML

Ha saltado a la luz una nueva forma de atacar a Internet
Explorer, mediante la combinación de marcos y eventos, que
provoca un error y el cierre de la aplicación. El problema
afecta a las versiones 4 y 5 del navegador de Microsoft
bajo cualquiera de las plataformas Windows.
La página que provoca la denegación de servicios está
compuesta por código JavaScript, hospedado en la cabecera,
y dos marcos que llaman a funciones de ese código. El
primer marco, que queda escondido, carga la función
blank(), la cual muestra simplemente una página en blanco
mediante las etiquetas .

El segundo marco, que es donde sucede toda la acción, llama
a la función JavaScript blank2(). El código visualiza una
sencilla página que a su vez llama cuando se carga a otra
función JavaScript, paintme(), a través del evento "onload".
A su vez, esta función, llama a rewrite() que muestra el
formulario que se visualiza finalmente en la página.


El formulario está compuesto por dos campos de tipo texto,
el primero contiene un evento "onChange" que llamará de
nuevo a la función paintme() que redibuja la página cuando
cambie el foco. Esto sucede cuando situados en el primer
campo introducimos algún valor y a continuación se "pincha"
en cualquier otro lugar de la página.

Esta acción provoca una excepción y el cierre del navegador
cuando el evento "onChange" es lanzado al cambiar el foco
desde el primer al segundo campo de texto. La demostración
en línea, donde se puede ver el código HTML íntegro, se
encuentra en la siguiente dirección:

http://www.e-softinc.com/iebug_001.html



Bernardo Quintero



domingo, 12 de septiembre de 1999

Hotmail sigue vulnerable

Hace menos de un mes saltaba la polémica a causa de un grave
problema de seguridad en Hotmail, el servicio de cuentas de
correo gratuitas más empleado del mundo. Si bien aquellos
agujeros fueron parcheados convenientemente por Microsoft, Georgi
Guninski ha descubierto un nuevo método para robar las
contraseñas de los usuarios.
El bug anterior permitía acceder al correo de cualquier usuario
de Hotmail sin necesidad de conocer su contraseña, en esta
ocasión, Georgi Guninski, ya habitual en esta sección de
noticias, ha descubierto un medio por el cual se puede conseguir
robar la contraseña del usuario que se desee.

El nuevo problema radica en la posibilidad de inyectar y ejecutar
código JavaScript dentro de un mensaje e-mail en Hotmail a través
del uso del tag

Más información:
Georgi Guninski:
http://www.nat.bg/~joro
News.com:
http://news.cnet.com/news/0-1005-200-117672.html?tag=st.cn.1fd2.



Antonio Ropero



sábado, 11 de septiembre de 1999

Windows NT sigue olvidando ficheros sensibles

Hace ya tiempo informábamos sobre un archivo olvidado por la
instalación de Microsoft BackOffice en el que se podían encontrar
datos relevantes de la configuración, pero parece ser que en las
instalaciones desatendidas de Windows NT se presenta un problema
similar.
En febrero de este año notificábamos que tras realizar la
instalación de MS BackOffice este producto dejaba sin borrar un
archivo temporal empleado durante el proceso de configuración del
sistema. Este archivo podía llegar a contener datos tan relevantes
como la password de administración del sistema.

Pero ahora Microsoft en un boletín de seguridad avisa a sus
usuarios de un problema similar en las instalaciones desatendidas
de Windows NT. Al realizar una instalación desatendida todos los
parámetros de la instalación se almacenan en el archivo
Unattend.txt. Durante el proceso de instalación desatendida de
Windows NT, este fichero se copia en %windir%\system32 como un
fichero temporal bajo el nombre de $winnt$.inf para instalaciones
desatendidas normales o bien como $nt4pre$.inf para instalaciones
que hacen uso de Sysprep (una utilidad para simplificar la
configuración del sistema).

Pero en ninguno de los casos el archivo temporal se borra tras
finalizar la instalación, con lo que todos los datos quedan al
alcance de cualquier usuario, pues el archivo puede ser abierto y
leído sin ninguna limitación de privilegios. Si en dicho archivo
existe información sensible, los datos quedarán comprometidos,
con la posibilidad de que dicho fichero contenga la password de
la cuenta de Administrador, o bien otras cuentas de usuarios.

El problema de las instalaciones desatendidas radica en que estas
suelen emplearse en grandes corporaciones, con cientos de puestos
a instalar, y se emplea este método para acelerar el proceso.
Además en este tipo de entornos, los usuarios suelen tener
cuentas con privilegios restringidos, por lo que acceder a este
tipo de ficheros con datos sensibles puede comprometer seriamente
la seguridad de todo el sistema. La única solución posible, es la
totalmente evidente, borrar de forma manual el archivo
comprometido.

Más información:
Boletín de seguridad de Microsoft
FAQ de Microsoft sobre el problema
Sysprep
HispaSec (La instalación de BackOffice compromete la seguridad)



Antonio Ropero



viernes, 10 de septiembre de 1999

Vulnerabilidad "ImportExportFavorities" en IE5

Internet Explorer 5.0, bajo las plataformas Windows 95/98/NT y
2000, permite crear y escribir en archivos locales a través del
método ImportExportFavorites(). Esta vulnerabilidad podría ser
aprovechada para ejecutar código, incluso virus o troyanos, de
forma remota en los sistemas Windows.
Interner Explorer 5 incluye una característica que permite a
los usuarios exportar la lista de favoritos de su navegador a
un archivo local, así como la operación contraria, importar la
lista de webs desde un archivo al apartado de favoritos del
navegador. Mediante esta utilidad Microsoft intenta facilitar
la sincronización de la lista de favoritos a los usuarios que
trabajan con distintos navegadores o varios ordenadores.

El método utilizado para esta función,
windows.external.ImportExportFavorites(), debería ser permitido
únicamente con determinados archivos del sistema local. Georgi
Guninski, nuestro habitual caza-agujeros en los navegadores,
ha demostrado que es posible burlar los controles restrictivos
que impone IE5, e invocar a este método para escribir en
ficheros que ejecuten comandos en el sistema. La vulnerabilidad
se agrava alpoder ser utilizado por un administrador de web para
llevar este ataque de forma remota, o mediante mensajes a
clientes de correo que soporten HTML.

Microsoft, que ha confirmado la noticia, ha calificado a esta
vulnerabilidad como de alto riesgo. Si bien, advierte que el
ataque depende de los privilegios que tenga el usuario en el
sistema desde el que se visite la página web maliciosa. Es
decir, en Windows NT el ataque está limitado si se trabaja
con una cuenta de usuario con privilegios restringidos.

Sin embargo, la realidad es que la mayoría de los usuarios suelen
operar en sus sistemas NT con cuentas de administrador, por no
mencionar que Windows 95/98 carece de esta posible protección.

La solución inmediata, a la espera del parche de Microsoft, pasa
por desactivar la opción de "Secuencias de comandos ActiveX"
accesible a través del menú Herramientas -> Opciones de Internet ->
Seguridad (pestaña) -> Personalizar nivel (botón).

Más información:
Demostración de Guninski
Boletín de Microsoft
FAQ de Microsoft



Bernardo Quintero



jueves, 9 de septiembre de 1999

Avance en la política de exportación criptográfica de EEUU

Los Estado Unidos han dado un paso adelante con el permiso
concedido a la empresa Entrust Technologies para la exportación
de tecnología criptográfica PKI de 128 bits a 43 países.
Como ya sabemos, la infraestructura de clave pública (Public Key
Infrastructure) de 128 bits establece los servicios y protocolos
necesarios para dar soporte a las aplicaciones de cifrado fuerte
enmarcado en los sistemas de clave pública. El uso de esta
tecnología estará disponible de forma única para comercio
electrónico, utilización médica, bancos e instituciones
financieras.

Este salto cualitativo se hará progresivamente utilizando las
filiales de Entrust Technologies a lo largo del mundo. Esta
apertura comenzó en países de confianza de la administración
norteamericana como Canadá y Suiza. Esto que podría parecer un
regalo de los Estados Unidos al mundo, no es más que otro forma
de asegurarse sus propias transacciones entre empresas
norteamericanas y sus filiales en el exterior. Según el estudio
de mercado de la firma International Data Corporation (IDC),se
espera que el crecimiento del comercio electrónico en el mundo
supondrá para el año 2003 la mitad del gasto en compras al por
menor, pasando de un 26% en 1998 al 46% previsible para el 2003.

Algunos quieren ver en esta acción una apertura, en la política
de exportación de tecnología criptográfica, hacía otras
finalidades no meramente gubernamentales o empresariales que
puedan cubrir las necesidades del usuario final.

Recordemos que la distribución de software criptográfico desde
EE.UU. está bajo el amparo de las Regulaciones Internacionales
sobre el Tráfico de Armas (ITAR). Bajo esta regulación se
requiere que un fabricante de tecnología criptográfica tenga que
registrarse en el Departamento de Estado de los EE.UU. y atajar
las severas restricciones que censuran a cualquier software que
implemente un sistema de cifrado.

Más información:
http://www.entrust.com/corporate/index.htm
http://www.entrust.com/news/1999/09_08_99.htm



Antonio Román



miércoles, 8 de septiembre de 1999

Sobrecarga de buffer en Windows a través del telnet

Microsoft publica un parche que viene a cubrir una nueva
vulnerabilidad en los sistemas Windows 95 y 98 a través de la
aplicación telnet.
La aplicación telnet de Windows 95 y Windows 98 (incluida la
Second Edition) es vulnerable a un ataque de sobrecarga de buffer
que puede llegar a ser explotado y permitir la ejecución de
aplicaciones en cualquier servidor remoto.

El cliente telnet distribuido con Windows 95 y Windows 98 tiene
un buffer sin comprobar de tal forma que cuando se pasa un
parámetro demasiado largo se puede producir una sobrecarga de
buffer. Si el ataque se realiza de forma cuidadosa, y el
parámetro se programa adecuadamente, se puede lograr la ejecución
de cualquier programa en el ordenador atacado.

El problema es más grave aun ya que el ataque se puede realizar
desde una página web. Es decir, un administrador malicioso puede
crear un link con una llamada al telnet especialmente preparada
con lo que conseguirá realizar el ataque de forma remota con todo
éxito.

Más información:
FAQ
Boletín de seguridad



Antonio Ropero



martes, 7 de septiembre de 1999

ALERTA VÍRICA: "Cholera", un i-worm de nueva generación

Tras haber advertido anteriormente acerca del peligro de virus
como Galadriel o Girigat, HispaSec informa a sus suscriptores,
una vez más en primicia, de la aparición de "Cholera", un nuevo
agente infeccioso capaz de afectar a sistemas Win32, que, a
juzgar por sus características, podría extenderse con gran
rapidez y aparecer en poco tiempo en las listas "in the wild".
Según la información que hemos podido encontrar en el website
de GriYo, conocido miembro de 29A y autor de "Cholera", sería
más correcto hablar de lo que él llama proyecto "SIMBIOSIS",
que consiste en un i-worm -el propio "Cholera"- que sirve de
portador para un virus, denominado "CTX". En HispaSec hemos
optado por referirnos a este agente infeccioso como "Cholera",
ya que, sin duda alguna, las infecciones que se produzcan a
partir del virus "CTX" habrán tenido origen en este i-worm.

"Cholera" llega a nuevos ordenadores por medio de mensajes de
correo electrónico, en forma de attach, como "SETUP.EXE", con
el clásico icono de programas de instalación autoexpandibles
(una caja abierta con un icono de programa de fondo). Estos
mensajes tienen como único contenido un smiley (":)"), lo que
nos hace pensar que, afortunadamente, serán pocos los que,
tras recibir el e-mail, se aventuren a ejecutar el fichero,
si bien es cierto que su tentador aspecto puede llevar a más
de uno a saciar su curiosidad.

Quienes pertenezcan a este último grupo, además de permitir
una infección vírica, quedarán decepcionados al ver que el
programa instalador no ha llegado en óptimas condiciones a
su ordenador... aparentemente. Esta inteligente artimaña le
sirve a "Cholera" para eliminar posibles sospechas, ya que
es el propio i-worm el que muestra el siguiente mensaje de
error, haciendo pensar que en realidad proviene de WinZip:

Cannot open file: it does not appear to be a valid archive.
If you downloaded this file, try downloading the file again.

Mientras esto sucede de cara al usuario, "Cholera" procede a
desencriptar todas aquellas cadenas de texto o constantes,
tales como nombres de APIs, susceptibles de levantar alguna
clase de sospecha a aquellos usuarios avanzados que, antes de
ejecutar el programa, hubiesen comprobado su contenido con
un editor hexadecimal. Quizás debido a que "Cholera" está
escrito en C++, el bucle de encriptación que protege a estas
cadenas es extremadamente simple, aunque siempre sorprende
una protección de estas características bajo la firma de un
escritor de virus que acostumbra a incluir mecanismos de
polimorfismo en todas sus creaciones.

Tras este importante paso, el i-worm "Cholera" se dispone a
lanzar un proceso multihilo, en forma de "split", para así
trabajar, por una parte, en cada una de las unidades de la
máquina infectada y, por la otra, en todas aquellas unidades
compartidas accesibles desde dicha máquina por medio de los
recursos en red. El funcionamiento de ambos "threads" está
basado en lo mismo: proceder iterativamente por cada una de
las unidades lógicas de cada máquina, comprobar cuáles de
ellas son discos duros y, por último, localizar el fichero
WIN.INI. Sorprende el hecho de que "Cholera", para llevar a
cabo este último cometido, compruebe la existencia de los
directorios "\WINDOWS", "\WIN95", "\WIN98", "\WIN" Y "\WINNT"
en lugar de emplear la conocida API "GetWindowsDirectory".
En cualquier caso, una vez localizado el fichero WIN.INI,
el i-worm busca en su interior el comando "RUN=", tras el
cual introduce su nombre y ubicación, con el fin de tener
asegurada su ejecución en posteriores arranques.

Es importante resaltar que el autor de "Cholera" ha tenido en
cuenta el hecho de que, bajo NT, el anterior comando pertenece
al registro de configuraciones y no a WIN.INI, de manera que
el i-worm mantiene también aquí su compatibilidad Win32. Esta
simple idea que acabamos de describir dota a "Cholera" de una
gran rapidez de expansión a través de redes locales, y en tan
sólo unos segundos el i-worm puede haber contagiado, sin ir
más lejos, a la redacción de un periódico al completo. Lo más
peligroso no es esto, sino que el radio de acción del i-worm
se vería multiplicado automáticamente por tantas veces como
número de ordenadores perteneciesen a esa red.

Una vez que "Cholera" ha asegurado su propia supervivencia y
la de "CTX" en las unidades locales, falta dar el último y
más peligroso paso: la propagación por e-mail. Este proceso
no tiene lugar hasta la siguiente ocasión en la que alguno de
los ordenadores vuelve a arrancar. Es entonces cuando "RUN="
activa al i-worm y éste permanece como una tarea activa en
background, atenta a la ejecución de aplicaciones de Internet
tales como CuteFTP, Internet Explorer, mIRC, Outlook Express
o Telnet, cuya presencia es prácticamente sintomática de
algún tipo de actividad en la red.

Es en este momento cuando "Cholera", por medio del registro
de configuraciones de Windows, extrae datos tales como el
nombre de usuario, el nombre de dominio, y el servidor SMTP
empleados por Outlook Express, con el fin de emplearlos para
enviarse a distintas direcciones de correo sin levantar tipo
alguno de sospecha. El autor de "Cholera" se jacta de emplear
sus propio motor de SMTP para no depender de aplicaciones
como Outlook Express o de las rutinas MAPI del sistema,
cuando, paradójicamente, depende de la presencia de Outlook
en una máquina para poder enviarse, en lugar de emplear un
servidor de SMTP fijo que admitiese conexiones anónimas.

Las direcciones de los destinatarios son extraídas por el
i-worm tras haber procesado, a lo largo del disco duro, la
totalidad de ficheros de extensión DBX, EML, HTM, HTML, IDX,
MBX, NCH y TXT, correspondientes a páginas web, ficheros de
texto plano y distintos formatos de buzones de correo. Una
vez que el proceso de recopilación ha terminado, "Cholera"
genera el tipo de e-mail anteriormente descrito, codificando
sus instrucciones en formato BASE64 con cabecera MIME, con
el fin de llegar en forma de attach a cada uno de los buzones
de correo e-mail a los que se ha enviado, y cerrando así su
ciclo vital, sin pasar por alto el hecho de que ha de borrar
toda huella que haya podido dejar, como por ejemplo en el
WIN.INI, y de que no se trata de un i-worm cuya única misión
es propagarse, ya que, a partir de este momento, es el virus
"CTX" el que toma el relevo de "Cholera".

Y lo cierto es que no se trata de ninguna broma... "CTX" se
nos presenta en un principio como el convidado de piedra, y
no por ello tiene menos importancia que "Cholera". Estamos
seguros, de hecho, de que aún el caso de que este último no
existiese, tampoco habríamos pasado por alto el hecho de
informar acerca del peligro de este sofisticado virus, que,
si bien no presenta tantas novedades como el i-worm, bien
merece cierta atención como complemento de "SIMBIOSIS".

Así como de "Cholera" comentamos que posee una débil rutina
de cifrado, de "CTX" nos vemos obligados a decir que está
protegido bajo una densa capa de encriptación polimórfica en
su variedad de mutación lenta, lo cual, sin lugar a dudas,
dificultará en gran medida la programación de los algoritmos
de detección y desinfección del virus, si bien su descifrado
manual no presenta demasiadas trabas.

A partir de aquí, lo que nos ofrece "CTX" es un pequeño pero
completo recital de técnicas avanzadas, tales como chequeo
de la integridad de su propio código y búsqueda de APIs por
medio de CRC32, lo que le ahorra la necesidad de emplear los
nombres de dichas APIs, dificultando su detección a primera
vista y su posterior análisis. También podemos observar que,
al igual que en el virus "HPS", nuestro protagonista procede
a efectuar el rastreo de la dirección de KERNEL32 por medio
de un escaneo en memoria, en lugar de otros métodos de corte
más convencional y quizás menos arriesgado.

Una vez que la fase de incialización se ve culminada con la
copia en memoria por medio de VirtualAlloc, la búsqueda de
ficheros, por medio de acción directa o "runtime", presenta
pocas particularidades con respecto a otros virus del mismo
autor de características similares, como puede ser el famoso
"Marburg", que en su día ocupó un lugar importante en las
listas de virus "in the wild". Precisamente es con este virus
con el que guarda un importante parecido en cuanto al método
de infección de aplicaciones de formato PE, en especial en
lo tocante al tratamiento de las relocaciones y a la ya
conocida técnica del "entry-point obscuring", que consiste en
no modificar el punto de entrada de los ejecutables, con el
fin de evitar ciertas alarmas heurísticas.

Desde HispaSec, a modo de resumen y tras haber analizado los
aspectos más peligrosos de este proyecto "SIMBIOSIS", formado
por el i-worm "Cholera" y el virus "CTX", hemos considerado
altmente recomendable hacer eco del peligro potencial de este
agente infeccioso entre el mundo de la seguridad informática,
con el único fin de poner freno por medio de la prevención.
Si bien la versión distribuida de "Cholera" no está depurada
de bugs al 100% y en un principio su técnica de expansión
no es tan inteligente como la empleada por el propio autor
en "Parvovirus", su creación anterior, es importante que las
compañías antivirus tomen medidas lo antes posible, y sólo de
esta manera se podrán evitar las posibles consecuencias del
proyecto "SIMBIOSIS", cuya única activación, de la mano de
"CTX", queda afortunadamente limitada al plano gráfico. Por
nuestra parte, y esperando que no suceda, nos comprometemos a
ofrecer un análisis en profundidad de este fenómeno vírico
de nueva generación en caso de que llegue a las listas "in
the wild", con el fin de mantener a nuestros suscriptores, y
al público en general, al tanto de todos sus detalles.

Más información:
Muestra de virus:hispasec@hispasec.com (AVs o similar)


Giorgio Talvanti



lunes, 6 de septiembre de 1999

ALERTA VIRUS: "Cholera", gusano portador de un virus

HispaSec informa en total primicia de la llegada a nuestro laboratorio de un
nuevo gusano de alta propagación que podría extenderse rápidamente entre los
usuarios de todo el mundo.
Última hora


Ha llegado a nuestro laboratorio un nuevo gusano, por lo que hemos podido
comprobar en un primer análisis el ejemplar llega al buzón de correo en
forma de mensaje proveniente de un conocido y con un archivo adjunto. El
asunto del mensaje tan sólo muestra un smiley (":)"),el cuerpo del mensaje
contiene la firma de la dirección del remitente y el archivo adjunto tiene
el nombre de "setup.exe", con el clásico icono de programas de instalación
autoexpandibles (una caja abierta con un icono de programa de fondo).


Otra característica destacable en "Cholera" es su capacidad de reproducirse a
través de las unidades compartidas en las redes locales. El gusano chequea
los recusos compartidos y detecta las unidades a las que tiene acceso, se
introduce en ellas copiándose, y modifica la entrada "RUN=" del fichero
WIN.INI para asegurarse su ejecución en el próximo inicio del sistema. A
destacar también, se encuentra el grado de compatibilidad que ofrece "Cholera",
que puede infectar a las diferentes versiones de Win32.


Pero el poder de este gusano va mucho más lejos, ya que una vez que ha
completado su ciclo de vida reproductivo como gusano se transforma en un
virus de Windows de última generación con características de encriptación
y polimorfismo. Todavía no estamos en condiciones de poder ofrecer
información adicional sobre él, sin embargo, nuestro especialista en virus,
Giorgio Talvanti, está en estos momentos realizando un análisis paralelo
sobre este ejemplar, del cual os ofreceremos una mayor información en breve.

Nuestro especialista informa que "Cholera" es la más reciente creación de GriYo,
el conocido creador de virus perteneciente al grupo 29A. Conociendo la
trayectoria de este programador podemos preveer que el virus no tenga ningún
efecto dañino directo, y que su payload se base en algún efecto gráfico,
tal y como ocurre en el resto de sus creaciones.




Antonio Ropero/Bernardo Quintero



domingo, 5 de septiembre de 1999

Ataque DoS a TFS Gateway 4.0

TFS Gateway 4.0 es vulnerable a un sencillo ataque remoto por
denegación de servicios consistente en enviar a través de esta
pasarela un mensaje de correo con un destinatario y remitente
erróneos.
TFS Gateway es desarrollado por TenFour, paradojas del destino,
autodenominados como los líderes mundiales en sistemas de correo
electrónico seguros. Consiste en un programa servidor que permite
conectar el sistema de correo de una red local a Internet. Los
sistemas soportados son Novell GroupWise, MS Exchange, MS Mail,
cc:Mail, Lotus Notes, FirstClass, MCI Mail y MSH.

La vulnerabilidad puede llevarse a cabo mediante un telnet al
puerto smtp del servidor del gateway con los siguientes
comandos:

HELO
MAIL FROM: cualquier cadena que no sea una dirección de correo
RCPT TO: dirección de correo inexistente (noexiste@servidor.com)
DATA
cualquier texto..
.
QUIT

Cuando TFS intenta enviar el mensaje a "noexiste@servidor.com"
recibirá un error, al no encontrar al destinatario. En estos
casos, está contemplado que el remitente reciba una copia del
mensaje notificándole que no ha sido posible enviarlo
correctamente. Como en el campo "MAIL FROM:" hemos incluido una
cadena que no es una dirección de correo el envío volverá a
fallar. Estos errores provocan en TFS Gateway un bucle infinito
que puede causar la denegación del servicio.

En los sistemas atacados el administrador puede parar de forma
manual el ataque. La solución definitiva consiste en instalar la
última versión del gateway ya que la versión 219 y posteriores
corrigen el problema.

Más información:
Security

Focus
TenFour



Bernardo Quintero



sábado, 4 de septiembre de 1999

Microsoft publica un parche contra ataques de denegación de servicios

El último parche de Microsoft viene a eliminar una vulnerabilidad
en las implementaciones de la pila TCP/IP en toda la familia
Windows.
El problema viene causado al recibir una serie de paquetes IGMP
fragmentados, dependiendo del sistema operativo que se emplee
pueden causar una gran variedad de problemas, pero bajo Windows
95 o 98 pueden hacer que se cuelgue la máquina. Windows NT 4.0
también ofrece la misma vulnerabilidad, pero la pila de este
sistema operativo hace que el ataque sea mucho más complejo.

Mediante el envío de paquetes IGMP fragmentados a una máquina
Windows 95, 98 o NT es posible desestabilizar el correcto
funcionamiento de la máquina. Los efectos de un ataque en el que
se emplee esta vulnerabilidad pueden ser muy diversos. Todo
dependerá del sistema operativo, la configuración y otros
factores, pero los efectos se pueden presentar en forma de
descensos del rendimiento del sistema, pérdida de las
funcionalidades de red o bloqueo total del sistema.

El protocolo IGMP (Internet Group Management Protocol) se emplea
para realizar IP multicasting, es decir, cuando el envío de datos
a una dirección IP puede alcanzar múltiples servidores. Otros
muchos protocolos hacen uso de las funciones del IGMP dentro de
sus especificaciones.

Más información:
Boletin de Seguridad Microsoft
FAQ sobre la vulnerabilidad
Parche para Windows 98
Parche para Windows NT 4.0



Antonio Ropero



viernes, 3 de septiembre de 1999

Problema de sobrecarga de buffer en Netscape Communicator

Casi todas las versiones de Netscape Communicator se encuentran
afectadas por un problema de sobrecarga de buffer en el código
que maneja los tags EMBED.
Una vez más un buffer sin chequear vuelve a generar un clásico
problema de sobrecarga de buffer. Este buffer se encuentra en la
opción "pluginspage" y puede llegar a explotarse a través de una
página web maliciosa. Las versiones afectadas van desde Netscape
Communicator 4.06 hasta la más moderna 4.61.

El ataque se realiza mediante la etiqueta EMBED mediante el cual
es posible la reproducción de archivos de audio o vídeo de una
forma sencilla en una página web. Esta etiqueta dispone como
parámetro opcional la opción "pluginspage", que permite especificar
la URL empleada por el proceso de instalación asistida en caso de
que el plugin necesario para cargar el archivo especificado en el
tag no se encuentre.

La cadena que causa la sobrecarga de buffer se especificará en la
opción pluginspage, de tal forma que el ataque puede llegar a
ejecutar cualquier comando en la máquina del usuario que visite
la página web maliciosa. El problema puede ser bastante serio ya
que mediante una programación cuidadosa del exploit se puede llegar
a incluir el código de un virus o troyano dentro del propio código
malicioso.

Por el momento Netscape no ha publicado ningún parche para solucionar
este problema.

Más información:
Securityfocus: http://www.securityfocus.com/level2/bottom.html?go=vulnerabilities&id=618
Demostraciones del problema:
http://www.ugtop.com/defcon0/hc/nc4x_ex/nc4x_ex.cgi
http://www.ugtop.com/defcon0/hc/nc4x_ex/nc4x_ex2.cgi
Código del exploit:
http://www.securityfocus.com/data/vulnerabilities/exploits/nc4x_ex.c
Bugtraq:
http://www.securityfocus.com/templates/archive.pike?list=1&msg=37CE8D9E384.9710DEFCON0@210.169.21.245



Antonio Ropero



jueves, 2 de septiembre de 1999

Nuevo dispositivo óptico para factorizar más rápido

Adi Shamir, la "S" del popular algoritmo RSA, ha diseñado un dispositivo
óptico (presentado en EuroCrypt'99) capaz de acelerar, en órdenes de
magnitud, uno de los pasos clave de los modernos algoritmos de
factorización. Ello permitirá "romper" claves asimétricas, consideradas
seguras hasta ahora, en un tiempo razonable.
Recordemos que muchos de los algoritmos criptográficos asimétricos basan
su seguridad en la dificultad de factorizar un número "n" cuando éste es
muy grande. Es decir, en encontrar los factores "p" y "q" tales que
"n=p*q". El RSA, por ejemplo, uno de los algoritmos asimétricos más
populares que existe, basa su seguridad en esta premisa.

La mayoría de los algoritmos modernos de factorización se basan en el
concepto de criba. En una primera etapa se localizan una serie de
números cuyos cuadrados módulo "n" tengan descomposiciones "suaves"
("smooth", en inglés) en factores primos pequeños. Esta primera etapa es
la más lenta, ya que un ordenador personal rápido requiere varios
segundos para validar cada valor tentativo, y la mayoría de los valores
evaluados resultan no ser válidos. Afortunadamente la comprobación de
cada valor puede realizarse de forma independiente, por lo que es
posible realizarlo en paralelo, en máquinas distintas.

Es interesante comentar que el número de valores "suaves" necesarios
para pasar a la siguiente etapa es un parametro que puede fijarse de
forma arbitraria. No obstante, este parámetro especifica también la
probabilidad de que un valor tenga una descomposición "suave". Es decir,
que si fijamos el parámetro para requerir muchos valores "suaves", la
probabilidad de que un valor dado sea "suave" es mayor que si cambiamos
el parámetro para requerir menos valores. Dado que evaluar y descartar
un valor, por no ser "suave", es una operación lenta, es preferible
aumentar las probabilidades de éxito aún a costa de necesitar más
valores "suaves" antes de pasar a la siguiente etapa. En la práctica se
suele trabajar tomando como base los primeros 200.000 números primos,
con lo que se necesitarán unos 200.000 valores "suaves".

Una vez localizados un cierto número de valores "suaves", un
superordenador (se requiere muchísima memoria RAM) procede a realizar
una eliminación gaussiana de la matriz resultante de combinar los
números "suaves" obtenidos en la etapa de criba, y tras una simple
operación de "máximo común denominador", se obtiene la factorización de
"n". Esta etapa tiene una duración reducida, comparada con la anterior.
No es fácilmente paralelizable, pero se trata de un paso muy rápido.

Adi Shamir, uno de los creadores del propio RSA, ha diseñado un
dispositivo óptico, de coste comparable al de una estación de trabajo de
gama media (5.000 dólares) capaz de realizar la etapa de criba, la
operación más costosa, mil veces más rápido que un ordenador de altas
prestaciones. En la práctica ello hubiera supuesto que la factorización
del reto RSA-140, completada en Febrero de 1.999 y que supuso el empleo
de doscientas estaciones de trabajo calculando a lo largo de cuatro
semanas, se hubiera podido completar en apenas unas pocas horas.

El dispositivo es un cilindro de un tamaño aproximado de 6*10 pulgadas
(aproximadamente 15*25 centímetros). Se llama TWINKLE, es muy sencillo y
barato de fabricar (no requiere componentes de precisión). Funciona,
básicamente, operando diodos electroluminiscentes (LEDs), cada uno de
ellos parpadeando con un período fijado en relación con el primo que
representa. Un ordenador conectado a TWINKLE le va enviando valores a
comprobar, proceso que consume menos de una centésima de segundo.
TWINKLE devolverá, a su vez, una estimación de la "suavidad" del número.
Bastará, por tanto, que el ordenador verifique informáticamente si el
número es o no "suave", tal y como lo hacía previamente. Pero ahora se
limitará a realizar esta operación exclusivamente con los valores que
TWINKLE marque como más probables, lo que supone una impresionante
mejora de rendimiento.

¿Cuáles son las implicaciones prácticas?. Una mejora de tres órdenes de
magnitud en el rendimiento de los algoritmos de factorización constituye
una ganancia considerable. Como ya hemos dicho, romper el reto RSA-140
supuso el empleo de 200 potentes máquinas durante cuatro semanas
(criba), más 100 horas de cálculo en un superordenador para la reducción
Gaussiana. Si se hubiesen empleado 200 TWINKLEs, el tiempo de criba se
hubiera reducido a apenas 40 minutos. Las 100 horas de cálculo finales
tendrían que efectuarse de todos modos, eso sí.

El reto RSA-140 factorizó una clave de 465 bits. Considerando
exclusivamente el tiempo de criba, la complejidad del NFS (Number Field
Sieve) es de O(e^(1.92*(ln(n)^(1/3))*(ln(ln(n))^(2/3))), obteniendo la
siguiente tabla aproximada:

Longitud de la clave Tiempo de criba
BITS Dígitos
465 140 X
512 154 6*X
565 170 47*X
615 185 278*X
665 200 1508*X
768 231 39154*X
1024 308 47285717*X
2048 616 5.3*10^16*X

A la luz de esta tabla, y mientras no se descubran algoritmos de
factorización más avanzados, las claves RSA de 1024 bits son todavía
seguras. Pero las claves de menos de 768 bits, especialmente las de 512
bits, son tremendamente vulnerables. Si tenemos en cuenta que las
versiones internacionales de los navegadores sólo pueden utilizar claves
asimétricas de 512 bits, vemos claramente que los certificados de
usuario que se generan en la actualidad son susceptibles de ataque por
entidades con recursos moderados.

Por cierto, TWINKLE es la abreviatura de "The Weizmann INstitute Key
Locating Engine".

Más información:

TWINKLE
http://www.rsa.com/rsalabs/html/twinkle.htm
http://www.rsa.com/pressbox/html/990504.html
http://www.rsa.com/rsalabs/html/twinkle_qa.html
http://jya.com/twinkle.eps
http://ceu.fi.udc.es/art-gpul/RSA_512bit_optic_cracker_design.txt
http://catless.ncl.ac.uk/Risks/20.38.html

Factorización RSA-140



Jesús Cea Avión
jcea@argo.es
http://www.argo.es/~jcea/



miércoles, 1 de septiembre de 1999

Los GUIDs y los MetaData en los documentos Microsoft Office (II)

Tal y como se explica en el boletín anterior, todos los documentos
creados con alguno de los paquetes "Office" (Microsoft Word, Excel,
PowerPoint) incluyen tanto un GUID como información histórica sobre
todas las modificaciones realizadas sobre dicho fichero (llamada
"MetaData"). Estos datos permiten inferir muchos datos de interés.
Esta información saltó a primera plana con el virus MELISSA. Dicho
virus se distribuye como un documento Microsoft Word con macros, y la
existencia de esta información fue decisiva a la hora de determinar
la autoría y el "proceso creativo" que dió lugar al virus.

A continuación se incluye la traducción de un email enviado por
"Richard M. Smith" al grupo de news "comp.risks", el 23 de Abril
de 1.999. Al final de este boletín se incluye la URL al documento
original.



Date: Fri, 23 Apr 1999 18:12:15 -0500
From: "Richard M. Smith"
Subject: Melissa, GUIDs, and VicodinES

He visto la discusión en comp.risks sobre el virus Melissa y los GUIDs,
y quiero distribuir alguna de la información que Rishi Khan
(rishi@udel.com) y yo mismo (smiths@tiac.net) descubrimos a lo largo de
la semana posterior a la difusión del virus.

Sobre el tema del GUID, se ha podido comprobar que el documento Melissa
tiene el mismo GUID que un documento Word con otro virus de macro,
llamado "Shiver". Shiver fue creado en Agosto de 1.998 por alguien
que usaba el alias de ALT-F11. Dado que los dos GUIDs son el mismo,
Rishi y yo hemos llegado a la conclusión de que Melissa fue creado
copiando el documento Shiver y reemplazando el código de dicho virus
por el código de Melissa. Esto fue confirmado por el hecho de que la
lista de páginas web en los dos documentos es idéntica, y que los "logs"
de revisiones de ambos documentos son iguales excepto que en el
documento Melissa aparece una entrada adicional.

Dado que la última modificación al documento Melissa fue sólo 30
minutos antes de que el virus fuera enviado al Web, parece que el virus
fue desarrollado en otro documento, y que luego se combinó con la lista
de páginas web de Shiver en el último minuto.

El GUID en el documento Melissa, muy probablemente, la dirección
Ethernet de la tarjeta de red del ordenador de ALT-F11, o de un
ordenador al que éste (o ésta) tuvo acceso en Agosto de 1.998.

¿Cuál es la conexión entre David L. Smith, la persona acusada de haber
distribuido el virus Melissa y VicodinES?. Por lo que parece hay muchas
conexiones, porque tanto David Smith como VicodinES tienen bastante
material en el web y han enviado numerosos mensajes a varios grupos
de news.

Una de las conexiones más interesantes se encontró en la propia
página web de VicodinES. Fredrik Bjork, de Suecia, me remitió a dicha
página unos días después de que el virus Melissa empezase a propagarse.
Fredrik había notado muchas similitudes entre el estilo de VicodinES y
el autor de Melissa. Pude descargar sobre diez documentos Word, de la
página web de VicodinES, que contenían varios virus de macro. En dos o
tres de dichos ficheros encontré el nombre de "David L. Smith" y sus
iniciales DLS. En particular, sólo ese nombre aparece varias veces en
el log de revisiones (por defecto, oculto) en uno de los virus
de VicodinES.

A continuación se muestra el volcado hexadeciman de un fichero Word
de Julio de 1.998:

12F0:FF FF 12 00 00 00 0D 00 44 00 61 00 76 00 69 00 ........|D.a.v.i.
1300:64 00 20 00 4C 00 20 00 53 00 6D 00 69 00 74 00 d. .L. .|S.m.i.t.
1310:68 00 23 00 43 00 3A 00 5C 00 57 00 49 00 4E 00 h.#.C.:.|\.W.I.N.
1320:44 00 4F 00 57 00 53 00 5C 00 44 00 65 00 73 00 D.O.W.S.|\.D.e.s.
1330:6B 00 74 00 6F 00 70 00 5C 00 43 00 6F 00 6E 00 k.t.o.p.|\.C.o.n.
1340:76 00 65 00 72 00 74 00 20 00 42 00 65 00 74 00 v.e.r.t.| .B.e.t.
1350:61 00 2E 00 64 00 6F 00 63 00 0D 00 44 00 61 00 a...d.o.|c...D.a.
1360:76 00 69 00 64 00 20 00 4C 00 20 00 53 00 6D 00 v.i.d. .|L. .S.m.
1370:69 00 74 00 68 00 35 00 43 00 3A 00 5C 00 57 00 i.t.h.5.|C.:.\.W.
1380:49 00 4E 00 44 00 4F 00 57 00 53 00 5C 00 54 00 I.N.D.O.|W.S.\.T.
1390:45 00 4D 00 50 00 5C 00 41 00 75 00 74 00 6F 00 E.M.P.\.|A.u.t.o.
13A0:52 00 65 00 63 00 6F 00 76 00 65 00 72 00 79 00 R.e.c.o.|v.e.r.y.
13B0:20 00 73 00 61 00 76 00 65 00 20 00 6F 00 66 00 .s.a.v.|e. .o.f.
13C0:20 00 43 00 6F 00 6E 00 76 00 65 00 72 00 74 00 .C.o.n.|v.e.r.t.
13D0:20 00 42 00 65 00 74 00 61 00 2E 00 61 00 73 00 .B.e.t.|a...a.s.
13E0:64 00 0D 00 44 00 61 00 76 00 69 00 64 00 20 00 d...D.a.|v.i.d. .
13F0:4C 00 20 00 53 00 6D 00 69 00 74 00 68 00 35 00 L. .S.m.|i.t.h.5.
1400:43 00 3A 00 5C 00 57 00 49 00 4E 00 44 00 4F 00 C.:.\.W.|I.N.D.O.
1410:57 00 53 00 5C 00 54 00 45 00 4D 00 50 00 5C 00 W.S.\.T.|E.M.P.\.
1420:41 00 75 00 74 00 6F 00 52 00 65 00 63 00 6F 00 A.u.t.o.|R.e.c.o.
1430:76 00 65 00 72 00 79 00 20 00 73 00 61 00 76 00 v.e.r.y.| .s.a.v.
1440:65 00 20 00 6F 00 66 00 20 00 43 00 6F 00 6E 00 e. .o.f.| .C.o.n.

1B90:00 1E 00 56 00 69 00 63 00 6F 00 64 00 69 00 6E ...V.i.c|.o.d.i.n
1BA0:00 45 00 53 00 20 00 56 00 42 00 41 00 20 00 53 .E.S. .V|.B.A. .S
1BB0:00 74 00 72 00 69 00 6E 00 67 00 20 00 43 00 6F .t.r.i.n|.g. .C.o
1BC0:00 6E 00 76 00 65 00 72 00 74 00 65 00 72 00 00 .n.v.e.r|.t.e.r..
1BD0:00 00 00 00 00 00 00 0D 00 44 00 61 00 76 00 69 ........|.D.a.v.i
1BE0:00 64 00 20 00 4C 00 20 00 53 00 6D 00 69 00 74 .d. .L. |.S.m.i.t
1BF0:00 68 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .h......|........

El log de revisiones de un documento Word es algo que Microsoft llama
"Metadada" y no puede visualizarse con el propio Word. Yo lo encontré
utilizando una utilidad de volcado hexadecimal. Microsoft tiene un
artículo que habla de los problemas de filtrar información a través del
"Metadata" de un documento Word:

http://support.microsoft.com/support/kb/articles/Q223/7/90.asp

Parece que la mayoría de los escritores de virus que crean virus de
macro para Word no han leído ese artículo de Microsoft :-). He visto
los nombres de mucha más gente en otras herramientas de construcción de
virus de macro que son distribuidas como documentos Word.

Richard M. Smith



Más Información:
Risks Digest



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