jueves, 30 de noviembre de 2000

CriptoRed cumple un año

El 1 de diciembre de 1999 comenzaba su andadura en Internet la Red
Temática Iberoamericana de Criptografía y Seguridad de la Información,
CriptoRed http://www.criptored.upm.es
En este primer año dedicado casi exclusivamente a formar un núcleo de
expertos, docentes universitarios, investigadores y destacados
profesionales de empresas en el sector de las TICs y la seguridad
informática, el balance no puede ser más positivo:

156 miembros que pertenecen a:
57 Universidades de 10 países (35 de España)
2 Centros de Investigación (CSIC y CINVESTAV)
2 Cámaras de Comercio Electrónico
22 empresas y organismos del sector

En este segundo año, el objetivo principal de la Red Temática, además
de la continua captación de nuevos miembros con los perfiles ya
indicados en especial en los países de Iberoamérica en donde todavía
continúa la fase de presentación del proyecto, se centrará en llenar
de contenidos el sitio Web: temarios de asignaturas, planes de
estudio, apuntes y guías de clase, libros electrónicos, bibliografía
comentada, software educacional, artículos, tesis doctorales,
normativas de seguridad, enlaces seleccionados, etc.

La Red Temática, que tiene como objetivo fundamental la creación de
una Comunidad Virtual Iberoamericana para el intercambio de
experiencias e información entre universidades, centros de
investigación y empresas del sector de la seguridad informática en
toda Iberoamérica, posiblemente migre hacia RedIRIS
http://www.rediris.es/ a comienzos del año 2001.



Dr. Jorge Ramió Aguirre
Coordinador General de CriptoRed


Más información:

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



miércoles, 29 de noviembre de 2000

"Hybris", un nuevo giro en la historia de los virus

El año pasado, aproximadamente a estas alturas, el virus "Babylonia"
rompió moldes en el mundo de la programación de este género de
engendros informáticos, y aportó nuevas y peligrosas posibilidades,
en simbiosis con Internet, hasta el momento desconocidas: era el
primer espécimen capaz de actualizar su código por medio de la Red.
Esta vez es el turno de "Hybris", un gusano programado por el mismo
autor que se presenta como el patógeno más difícil de combatir, así
como, probablemente, el más complejo aparecido hasta el momento.
El funcionamiento básico de este "i-worm" recuerda al de "Happy99",
en cuanto a que, tras haber sido ejecutado por el usuario, procede
a instalarse en el sistema modificando WSOCK32.DLL, la librería de
comunicaciones por Internet empleada por Windows, con el fin de poder
enganchar las funciones "connect", "recv" y "send", por medio de las
cuales el gusano es capaz de monitorizar las acciones claves que
están teniendo lugar en cada conexión a la Red. Por si esto fuera
poco, "Hybris" además modifica la porción de código de carga inicial
de esta librería con su propio código, tras lo cual cifra el
fragmento original, para dificultar sobremanera -incluso convertir
en una decisión arriesgada- su desinfección.

Como suele suceder, en caso de que el fichero WSOCK32.DLL esté en
memoria, activo, el "malware" no será capaz de modificarlo, por lo
que procederá a efectuar una copia del mismo, empleando un nombre
generado de manera aleatoria, e incluirá una instrucción para poder
renombrarlo en el archivo WININIT.INI, que llevará a cabo esta tarea
en el siguiente inicio de sesión del sistema operativo afectado. A
este respecto es importante comentar que, asimismo, "Hybris" crea
una entrada en el registro de configuraciones del usuario por medio
de la cual ejecuta la copia del código maligno tras el siguiente
arranque, una operación aparentemente redundante cuyo única causa
sería, aparentemente, la necesidad que tiene el gusano de asegurarse
de que la sustitución de WSOCK32.DLL se hace efectiva.

A partir del momento en que la librería infectada es cargada en la
memoria del ordenador, el patógeno pasa a controlar absolutamente
todas las comunicaciones que tienen lugar por medio de Internet, a
partir de las cuales es capaz de interceptar nuevas direcciones de
correo electrónico a las que enviar copias de sí mismo. Hasta el
momento se han detectado numerosas posibilidades en torno al aspecto
de los e-mails portadores; las más populares son las enviadas por el
remitente "Hahaha ", que contienen un breve
fragmento en alusión al cuento de Blancanieves, traducido a portugués,
español, inglés o francés, emparejado con un asunto fijo y cuatro
posibles nombres de fichero adjunto para cada una, y con referencias
de tipo pornográfico:

Asunto: Branca de Neve pornô!
Posibles adjuntos: branca de neve.scr
atchim.exe
dunga.scr
anão pornô.scr
Texto:
Faltava apenas um dia para o seu aniversario de 18 anos. Branca de
Neve estava muito feliz e ansiosa, porque os 7 anões prometeram uma
*grande* surpresa. As cinco horas, os anõezinhos voltaram do trabalho.
Mas algo nao estava bem... Os sete anõezinhos tinham um estranho
brilho no olhar...

Asunto: Enanito si, pero con que pedazo!
Posibles adjuntos: enano.exe
enano porno.exe
blanca de nieve.scr
enanito fisgon.exe
Texto:
Faltaba apenas un dia para su aniversario de de 18 años. Blanca de
Nieve fuera siempre muy bien cuidada por los enanitos. Ellos le
prometieron una *grande* sorpresa para su fiesta de compleaños. Al
entardecer, llegaron. Tenian un brillo incomun en los ojos...

Asunto: Snowhite and the Seven Dwarfs - The REAL story!
Posibles adjuntos: sexy virgin.scr
joke.exe
midgets.scr
dwarf4you.exe
Texto:
Today, Snowhite was turning 18. The 7 Dwarfs always where very
educated and polite with Snowhite. When they go out work at mornign,
they promissed a *huge* surprise. Snowhite was anxious. Suddlently,
the door open, and the Seven Dwarfs enter...

Asunto: Les 7 coquir nains
Posibles adjuntos: blancheneige.exe
sexynain.scr
blanche.scr
nains.exe
Texto:
C´etait un jour avant son dix huitieme anniversaire. Les 7 nains, qui
avaient aidé `blanche neige´ toutes ces années après qu´elle se soit
enfuit de chez sa belle mère, lui avaient promis une *grosse* surprise.
A 5 heures comme toujours, ils sont rentrés du travail. Mais cette
fois ils avaient un air coquin...

Asimismo, se han detectado versiones más recientes de "Hybris", con
mensajes de apariencia distinta, cuyo asunto está compuesto a partir
de combinaciones de las siguientes opciones, emparejando una palabra
de la primera columna con otra de la segunda:

Anna sex
Raquel Darian sexy
Xena hot
Xuxa hottest
Suzete cum
famous cumshot
celebrity rape horny
[...] [...]

Y acompañados por un fichero anexado, bajo alguno de los nombres de
la siguiente lista:

Anna.exe
Raquel Darian.exe
Xena.exe
Xuxa.exe
Suzete.exe
famous.exe
celebrity rape.exe
leather.exe
sex.exe
sexy.exe
hot.exe
hottest.exe
cum.exe
cumshot.exe
horny.exe
anal.exe
gay.exe
oral.exe
pleasure.exe
asian.exe
lesbians.exe
teens.exe
virgins.exe
boys.exe
girls.exe
SM.exe
sado.exe
cheerleader.exe
orgy.exe
black.exe
blonde.exe
sodomized.exe
hardcore.exe
slut.exe
doggy.exe
suck.exe
messy.exe
kinky.exe
fist-fucking.exe
amateurs.exe


Y es que, precisamente, la capacidad que tiene "Hybris" de cambiar
su código por medio de actualizaciones enviadas con "plug-ins" es
una de sus principales características, que, si bien aparentemente
idéntico al concepto aportado por "Babylonia", presenta un par de
novedades fundamentales que convierten a este espécimen en todo un
quebradero de cabeza para las compañías antivirus interesadas en
programar antídotos para combatirlo: el patógeno recibe "plug-ins"
por medio de los grupos de noticias de Internet, y éstos aparecen
cifrados con algoritmo RSA y una llave de 128 bits, de tal modo
que resulta prácticamente imposible impedir que este gusano se siga
actualizando por medio de Internet, sin posibilidad de bloquear
direcciones o de cerrar cuentas en las que las actualizaciones se
encuentren.

Así, por medio del grupo de noticias "alt.comp.virus", "Hybris" va
recibiendo nuevos "plug-ins" enviados por su autor, que, tras haber
sido procesados, son automáticamente instalados y asimilados por
cada una de las copias del espécimen. Esta característica es la que
ha llevado al conocido foro de debate orientado hacia la lucha
antivírica a verse colapsado en las últimas semanas por un verdadero
aluvión de mensajes de origen anónimo y de contenido ininteligible,
que en un principio hicieron pensar a los contertulios que no se
trataba más que de la broma pesada de un "spammer".

Este tipo de "plug-ins" que el patógeno recibe por medio del grupo
de noticias "alt.comp.virus" presenta un peculiar formato por medio
del cual "Hybris" es capaz de distinguir el tipo de actualización y
la versión de la misma, para así saber si es necesario descargar el
mensaje e instalar el nuevo componente (almacenado en el disco duro
con un nombre generado de forma aleatoria) en el sistema.

Hasta el momento se han podido encontrar varios "plug-ins" que, por
suerte, todavía no resultan muy peligrosos, si bien es cierto que
el "i-worm" en cualquier momento se encuentra en condiciones de
modificar su cifrado y el aspecto de los mensajes que envía,
con el fin de obligar a las compañías antivirus a también actualizar
la información de sus vacunas y descripciones. Por ahora, Vecna, el
autor de "Hybris", ha publicado componentes que:

1) Infectan archivos RAR y ZIP, insertando una copia de su código
en los mismos, y suplantando a los archivos EXE presentes, en
caso de existir.
2) Envían copias del espécimen a máquinas afectadas por el troyano
"SubSeven", por medio de la puerta trasera que éste deja abierta.
3) Cifran los ficheros adjuntos con un algoritmo polimórfico.
4) Infectan ficheros EXE de formato MZ y PE (DOS y Win32).

Por el momento se desconocen datos oficiales por parte del organismo
encargado de ofrecer una aproximación de la prevalencia de los virus
"en libertad" (`in the wild´), la "WildList", pero el número de
usuarios infectados con "Hybris" parece más que significativo, a
tenor de la cantidad de e-mails recibidos por el laboratorio de
Hispasec y por el número de "plug-ins" que están siendo enviados
desde hace semanas al grupo de noticias "alt.comp.virus". El mejor
consejo ante una alerta como ésta es el de la prevención: cualquier
fichero adjunto no solicitado, por fiable que sea el remitente,
debería ser automáticamente enviado a la papelera de reciclaje, con
lo que se puede evitar de raíz ser afectado por cualquier "i-worm".



Giorgio Talvanti
talvanti@hispasec.com


Más información:

I-Worm.Hybris
http://www.avp.ch/avpve/worms/email/hybris.stm

Hybris
http://www.f-secure.com/v-descs/hybris.htm

W32.Hybris.gen
http://www.sarc.com/avcenter/venc/data/w32.hybris.gen.html

W32/Hybris.gen@M
http://vil.nai.com/vil/dispVirus.asp?virus_k=98873

W32/Hybris
http://www.pandasoftware.es/enciclopedia/gusano/W32Hybris_1.htm

W32/Hybris-B
http://www.sophos.com/virusinfo/analyses/w32hybrisb.html

TROJ_HYBRIS.C
http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=TROJ_HYBRIS.C



martes, 28 de noviembre de 2000

CyberPatrol no protege el envío de datos sensibles

CyberPatrol, el software para el control de contenidos durante
la navegación por Internet, permite registrar el programa a través
de un formulario que incluye en su versión de demostración. Los
datos recogidos para proceder al pago y registro de la aplicación
son enviados a su servidor en texto claro, con la excepción del
número de tarjeta de crédito, que intentan proteger en vano con
un simple cifrado por sustitución fácil de invertir.
En vez de utilizar una sesión segura para el envio de información
a su servidor, SSL por ejemplo, CyberPatrol utiliza el método
POST a través de una conexión HTTP normal, con lo que los datos
viajan por la Red sin ninguna protección.

La información facilitada por parte del usuario en el registro,
tal como dirección de correo, domicilio, o la fecha de expiración
de la tarjeta, viaja sin ningún tipo de cifrado, al alcance de
cualquiera que intercepte la comunicación. En el caso del número
de la tarjeta de crédito utiliza un sencillo método de sustitución
de los dígitos por otros caracteres según la siguiente tabla:


0=z, 1={, 2=x, 3=y, 4=%7E, 5=., 6=|, 7=}, 8=r, 9=s

Alguien que intercepte la comunicación podrá realizar la operación
inversa para conseguir el número de la tarjeta de crédito.



Antonio Román Arrebola
antonio_roman@hispasec.com


Más información:


CyberPatrol
http://www.cyberpatrol.com

Microsys CyberPatrol Insecure Registration Vulnerability
http://www.securityfocus.com/archive/1/146602



lunes, 27 de noviembre de 2000

El gusano "Req" roba información de un banco de Suiza

Recientemente, en medio de una oleada vírica que ha dejado tras su
paso una considerable cantidad de nuevos gusanos (`i-worms´), ha
aparecido "Req", un espécimen que, una vez ejecutado en una máquina
remota, roba documentos generados por un programa del Union Bank de
Suiza, en caso de existir, y los envía al autor del "malware".
Se trata de un gusano programado en lenguaje VBS (`Visual Basic
Script´), al igual que otros más famosos como "I love you". Este
espécimen es capaz de funcionar sólo en aquellos ordenadores en los
que se haya instalado una copia de la versión comercial de Microsoft
Outlook, que es el programa que emplea como pasarela para poder
enviarse a otras direcciones de correo electrónico y proseguir así
su ciclo reproductor a través de la Red.

"Req" se presenta en forma de e-mail, cuyo único texto es "Thank
for your order and your confidence in us." (gracias por su pedido
y su confianza en nosotros); el mensaje lleva como título la frase
"requested info" (información solicitada), e incluye un fichero
adjunto, el archivo portador del código maligno, bajo el nombre
"REQUESTED_INFO.DOC.vbs". El espécimen aprovecha de esta forma la
posible ingenuidad de quien reciba el mensaje y se decida a abrirlo,
pensando que se trata de un documento (.DOC), y no de un formato de
secuencia de comandos (.vbs) que puede ocultar un virus, algo que
resulta mucho más difícil de detectar en el supuesto de que, según
la configuración de cada sistema, llegase a omitirse el ".vbs" del
final, apareciendo ".DOC" como única extensión.

Una vez ejecutado, el gusano procede a buscar en el disco duro del
usuario infectado documentos generados por un programa que el Union
Bank de Suiza proporciona a sus clientes para efectuar pagos por
medio de Internet (una especie de "resguardos electrónicos") y, en
caso de encontrar alguno, lo envía a tres direcciones de correo,
pertenecientes al autor del espécimen.

El ciclo vital de "Req" se completa en el momento en que accede a
la libreta de cuentas de Microsoft Outlook (en la que, por defecto,
se almacenan las direcciones de aquellas personas a las que el
propietario del sistema envía e-mails), y manda una copia de su
código a cada una de las entradas existentes, sin fijar en ningún
caso un límite máximo de destinatarios, a diferencia de otros virus
o gusanos, como por ejemplo "Melissa".



Giorgio Talvanti
talvanti@hispasec.com


Más información:

I-Worm.Req

http://www.avp.ch/avpve/worms/email/req.stm

VBS/Req.A@MM
http://vil.nai.com/vil/virusChar.asp?virus_k=98898

VBS_REQ.A
http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=VBS_REQ.A



domingo, 26 de noviembre de 2000

Computación cuántica: la última frontera (1ª parte)

Desde que el hombre comenzó a comunicarse con sus semejantes ha
experimentado la necesidad de proteger su información confidencial de
oídos y ojos indiscretos. A lo largo de la historia se han utilizado
distintas técnicas de protección, desde la esteganografía para
ocultar la existencia de los propios mensajes secretos, de manera que
pasaran desapercibidos al enemigo, como por ejemplo gracias a la
tinta invisible o a los micropuntos en letras de libros o periódicos,
hasta la criptografía, para cifrar el contenido de los mensajes, de
forma que sean ininteligibles para cualquiera que no posea la clave
de descifrado, como la cifra de César, las rótulas de Tritemio, o los
cuadrados de Polibio.
Tradicionalmente, la criptografía se ha enfrentado a dos problemas
bien distintos, pero interrelacionados. Por una lado, el cifrado de
los mensajes para ocultar la información que se desea transmitir.
Muchos algoritmos y protocolos han sido propuestos, hasta llegar a
los actuales, como DES, IDEA o Rijndael. No podemos olvidar la cinta
aleatoria, el único sistema de cifrado perfectamente seguro que
existe, probado matemáticamente, consistente en generar como clave
una secuencia aleatoria de unos y ceros, que se suma al mensaje,
previamente convertido en binario. El receptor cuenta en su poder con
una cinta idéntica, realiza la suma del mensaje cifrado con ella y
obtiene así el texto original. A pesar de su aparente sencillez, un
mensaje cifrado por este procedimiento resulta absolutamente
indescifrable, ni en un año ni en millones de eones, siempre que la
cinta se utilice una sola vez (de ahí su nombre en inglés, "one-time
pad").

Entonces, si este sistema es tan perfecto, ¿por qué no lo usamos
todos? Éste es precisamente el segundo problema de la criptografía:
la distribución de la clave, en otras palabras, ¿cómo hacer llegar la
clave o la cinta aleatoria al destinatario? Si se envía por medio de
un mensajero de confianza, podría caer en manos enemigas o ser
copiada sin que nos enterásemos. Si se transmite por teléfono o a
través de Internet, la comunicación podría ser igualmente
interceptada. En definitiva, no existe forma segura de poner en
conocimiento del destinatario el valor de la cinta, es decir, de la
clave. Por este motivo, se han desarrollado protocolos y algoritmos
que permitan compartir secretos a través de canales públicos. Hoy en
día, el más usado se basa en criptografía de clave pública, como el
famoso RSA.

El funcionamiento de estos algoritmos se fundamenta en la utilización
de dos claves, una pública, conocida por todos, con la que se cifra
la información secreta, y otra privada, sólo conocida por su
propietario, con la que descifra el criptograma anterior, recuperando
así la información secreta. Matemáticamente, estos algoritmos se
basan en la facilidad de realizar operaciones en un sentido y en la
dificultad de realizarlas en sentido contrario. Para entenderlo
intuitivamente: resulta muy sencillo elevar mentalmente al cuadrado
un número, por ejemplo, 8. Sin embargo, resulta muy complicado
extraer mentalmente la raíz cuadrada del mismo número, 8. RSA se basa
en la dificultad de factorizar números grandes. Usando los
ordenadores más potentes, se tardaría varias veces la edad del
universo en factorizar una clave RSA.

Así estaban las cosas, hasta que hizo su aparición en escena la
computación cuántica. Cuando ya se está alcanzando el límite
preconizado por la ley de Moore, que pone límite a la miniaturización
de los chips, más allá del cual no puede seguirse reduciendo el
tamaño de los transistores, los ojos de la industria se han vuelto
con esperanza hacia los ordenadores cuánticos. Estos ingenios se
basan en las propiedades cuánticas de la materia para almacenar
información sirviéndose, por ejemplo, de dos estados diferentes de un
átomo o de dos polarizaciones distintas de un fotón.
Sorprendentemente, además de los dos estados, representando un 1 y un
0, respectivamente, el átomo puede encontrarse en una superposición
coherente de ambos, esto es, se encuentra en estado 0 y 1 a la vez.
En general, un sistema cuántico de dos estados, llamado qubit, se
encuentra en una superposición de los dos estados lógicos 0 y 1. Por
lo tanto, un qubit sirve para codificar un 0, un 1 ó ¡0 y 1 al mismo
tiempo! Si se dispone de varios qubits, se podrían codificar
simultáneamente cantidades de información impresionantes.

Pero la computación cuántica puede ofrecer mucho más que gran
capacidad de almacenamiento de información y velocidad de
procesamiento. Puede soportar formas completamente nuevas de realizar
cálculos utilizando algoritmos basados en principios cuánticos. En
1994 Peter Shor, de los laboratorios AT&T Bell, inventó un algoritmo
para ordenadores cuánticos que puede factorizar números grandes en un
tiempo insignificante frente a los ordenadores clásicos. En 1996, Lov
Grover, también de los laboratorios Bell, ideó otro algoritmo que
puede buscar en una lista a velocidades increíbles. ¿Qué tienen de
particular estos algoritmos desde el punto de vista de la
criptografía?

Suponen la peor pesadilla de todo criptógrafo. El algoritmo de
factorización de Shor demolería de una vez por todas a RSA. Si
llegase a construirse un ordenador cuántico capaz de implementarlo
eficientemente, se hundiría todo el edificio de la PKI: adiós al
correo confidencial, al comercio electrónico, a la privacidad en
línea. Por su parte, el algoritmo de Grover permite romper DES o
cualquier otro algoritmo de cifrado de clave secreta, como Rijndael o
RC5, en un tiempo que es raíz cuadrada del que se tardaría con un
ordenador clásico. En otras palabras, todos los secretos guardados
con claves de hasta 64 bits, hoy en día consideradas invulnerables,
caerían como un castillo de naipes. Supondría el fin de la
criptografía tal y como la conocemos actualmente. Por fortuna,
todavía no se ha construido un ingenio tal, ni se espera avanzar
hasta estos extremos en los próximos 15 ó 25 años.

Como señala Simon Singh en su excelente libro "The Code Book", a
medida que la información se convierte en uno de los bienes más
valiosos, el destino político, económico y militar de las naciones
dependerá de la seguridad de los criptosistemas. Sin embargo, la
construcción de un ordenador cuántico acabaría con la privacidad, con
el comercio electrónico y con la seguridad de las naciones. Un
ordenador cuántico haría zozobrar el ya frágil equilibrio mundial. De
ahí la carrera de las principales naciones por llegar primero a su
construcción. El ganador será capaz de espiar las comunicaciones de
los ciudadanos, leer las mentes de sus rivales comerciales y
enterarse de los planes de sus enemigos. La computación cuántica,
todavía en mantillas, representa una de las mayores amenazas de la
historia al individuo, a la industria y a la seguridad global.



Gonzalo Álvarez Marañón
criptonomicon@iec.csic.es


Más información:

Criptonomicon
http://www.iec.csic.es/criptonomicon/



sábado, 25 de noviembre de 2000

"Romeo y Julieta", un gusano de dos piezas inseparables

La imaginación de los programadores de virus ha llegado a rescatar
un clásico de Shakespeare, "Romeo y Julieta", para representar con
el amor de éstos la dependencia total de los dos módulos que componen
el "i-worm" que lleva el mismo nombre, un peligroso espécimen de
"malware", descubierto recientemente en Polonia, que es capaz de
activarse, al igual que "Bubbleboy", con sólo leer un e-mail portador.

El gusano viaja por medio de Internet dentro de dos ficheros, con los
nombres de "MYJULIET.CHM" y "MYROMEO.EXE", que son anexados a e-mails
que presentan una de las siguientes opciones (elegida aleatoriamente)
como asunto:

Romeo&Juliet
:))))))
hello world
!!??!?!?
subject
ble bla, bee
I Love You ;)
sorry...
Hey you !
Matrix has you...
my picture
from shake-beer

Por medio del ya famoso agujero de seguridad "script.typelib" común
a las versiones de Outlook, la versión comercial del cliente de correo
de Microsoft, "Romeo y Julieta" consigue que "MYJULIET.CHM" sea
automáticamente ejecutado cada vez que uno de los destinatarios de
los mensajes electrónicos por medio de los que el gusano se difunde
se dispone a tan sólo leer el contenido del e-mail portador.

Una vez que esto sucede, el archivo CHM descomprime sus contenidos,
y extrae un "script" necesario, programado en VBS (`Visual Basic
Script´), mediante el cual, aprovechando los privilegios concedidos
por defecto por Windows para la ejecución de programas en modo local,
corre el código del fichero "MYROMEO.EXE".

Programado en Delphi y comprimido con UPX hasta quedar en un tamaño
aproximado a los 30 kilobytes de longitud, este segundo componente
de "Romeo y Julieta" se limita a acceder a la libreta de direcciones
del usuario infectado y, por medio de Microsoft Outlook, enviar una
copia propia y de "MYJULIET.CHM" a cada una de las cuentas existentes
en la lista de destinatarios posibles, seleccionando como asunto del
mensaje una de las posibilidades anteriormente presentadas.

Afortunadamente, y debido a un error de programación, este gusano
tiene dificultades para funcionar en algunas versiones de Windows,
en función del lenguaje activado por defecto, que, en caso de ser
inglés, asegura un comportamiento defectuoso por parte del "malware".



Giorgio Talvanti
talvanti@hispasec.com


Más información:

I-Worm.Blebla
http://www.avp.ch/avpve/worms/email/blebla.stm

BleBla
http://www.f-secure.com/v-descs/blebla.htm

W32.Blebla.Worm
http://www.symantec.com/avcenter/venc/data/w32.blebla.worm.html

W32/BleBla@MM
http://vil.nai.com/vil/dispVirus.asp?virus_k=98894

Worm/Verona.A
http://www.pandasoftware.es/enciclopedia/gusano/I-WormVeronaA_1.htm

W32/Verona
http://www.sophos.com/virusinfo/analyses/w32verona.html

TROJ_BLEBLA.A
http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=TROJ_BLEBLA.A



viernes, 24 de noviembre de 2000

El gusano "Sonic", capaz de actualizar su código

Uno de los "i-worms" más destacados de las últimas semanas ha sido,
sin lugar a dudas, "Sonic", de probable origen francés. El patógeno
forma parte de un reducido pero cada vez más abundante grupo de
especímenes de índole vírica capaces de autoactualizar su código
por medio de Internet, siguiendo así el camino marcado ya el pasado
año por el virus "Babylonia".
Sin embargo, el método empleado por "Sonic" presenta una serie de
originales y peligrosas innovaciones con respecto a los virus de
características similares conocidos hasta el momento: en lugar de
instalar su código principal en el sistema y luego ir añadiendo al
mismo pequeños componentes extra o "plug-ins", este gusano ofrece
un punto de vista alternativo.

El espécimen, que se reproduce por medio de mensajes de correo
electrónico vacíos, con la frase "Choose your poison" (elige tu
veneno) como asunto y un fichero adjunto llamado "girls.exe", está
compuesto por dos módulos: un cargador, que es el que viaja en los
e-mails que "Sonic" envía, y un portador del código principal, que
es el que contiene las rutinas necesarias para la reproducción del
patógeno por medio de Internet.

El cargador, de una longitud aproximada de 25 kilobytes, tras haber
sido comprimido con UPX, tiene por misión instalarse en el sistema
sin levantar las sospechas del usuario, y, posteriormente, descargar
de una página web el módulo portador. Así, una vez ejecutado, el
programa procede a mostrar un mensaje de error:

u:\Ubicación\girls.exe n´est pas une application Win32 valide.

Donde "u:\Ubicación" es la especificación correcta del directorio
desde el que está siendo ejecutado el cargador. Mientras tanto, el
"i-worm" habrá ya procedido a colocar una copia de su código en la
carpeta de sistema, bajo el nombre "GDI32.EXE" (que no debe ser en
ningún caso confundido con "GDI.EXE" o "GDI32.DLL", ficheros ambos
legítimos de Windows); tras este paso, "Sonic" pasa a incluir una
nueva entrada en el registro de configuraciones, en:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

El propósito de esta operación consiste en la necesidad del gusano
de asegurarse su residencia en memoria después de cada arranque del
sistema, ya que su trabajo lo desempeña como un proceso oculto que
nunca se llega a cerrar, hasta que la sesión actual de Windows llega
a su fin. El motivo no es otro que la monitorización permanente de
las conexiones a Internet: el cargador debe buscar en la Red a su
media naranja, el portador del código principal de "Sonic".

Para esto, el programa se conecta con un servidor web, por medio del
puerto estándar para este tipo de comunicaciones, el 80, y obtiene
un fichero llamado "LASTVERSION.TXT", que contiene un número formado
por dos dígitos, empleado para representar la última versión del
gusano que se encuentre disponible; en caso de ser más reciente que
la ya existente en el sistema, el módulo cargador procederá entonces
a descargar otros dos ficheros del mismo servidor: "GATEWAY.ZIP", que
contiene una versión actualizada del propio cargador, y "xx.ZIP",
donde "xx" es el número especificado en "LASTVERSION.TXT", que se
corresponde al último módulo portador disponible.

De esta ingeniosa forma, el autor del gusano se puede permitir el
lujo de efectuar cualquier cambio en el código de su creación, algo
que hasta el momento, a otros especímenes similares, les resultaba
imposible, pues eran capaces tan sólo de añadir módulos de código
adicionales al "malware" principal. Así, una vez instalado el módulo
portador de "Sonic", de unos 40 kilobytes de longitud (también
comprimidos con UPX), éste procede a efectuar una autocopia en el
directorio de sistema, como "GDI32A.EXE", tras lo cual accede a la
libreta de direcciones del usuario infectado y, por medio del cliente
de correo electrónico Microsoft Outlook, envía e-mails a cada una
de las entradas existentes, independientemente de cuántas sean, a
las que adjunta la versión más reciente del módulo cargador.



Giorgio Talvanti
talvanti@hispasec.com


Más información:

Sonic
http://www.f-secure.com/v-descs/sonic.htm

I-Worm.Sonic
http://www.avp.ch/avpve/worms/email/sonic.stm

W32.Sonic.Worm
http://www.symantec.com/avcenter/venc/data/w32.sonic.worm.html

W32/Sonic.worm
http://vil.nai.com/vil/dispVirus.asp?virus_k=98868

I-Worm/Sonic.B
http://www.pandasoftware.es/enciclopedia/gusano/IWormSonicB_1.htm

W32/Sonic-B
http://www.sophos.com/virusinfo/analyses/w32sonicb.html

TROJ_SONIC.B
http://www.antivirus.com/vinfo/virusencyclo/default5.asp?VName=TROJ_SONIC.B



jueves, 23 de noviembre de 2000

Agujero en la máquina Java de Lotus Notes Client R5

Lotus Notes Client R5, la herramienta de mensajería y colaboración,
cuenta con su propio navegador web y una máquina virtual Java para
poder visualizar los applets. Existe una vulnerabilidad en la
característica ECL (Execution Control List), propietaria de la máquina
virtual Java de Lotus, que permite chequear mediante un applet, de
forma remota, la existencia o no de ficheros en una trayectoria
determinada.
La vulnerabilidad, descubierta por Hiromitsu Takagi, fue reportada por
él mismo a Lotus el 3 de Mayo del presente año. Cuando ya transcurren
más de 6 meses, y después de continuos contactos por correo
electrónico y teléfono, Lotus no ha facilitado solución alguna al
respecto. Takagi, ante la falta de una respuesta satisfactoria, ha
optado por hacer pública la vulnerabilidad en busca de una reacción
acorde con el problema.

Un punto más a favor de la necesidad de las políticas "full
disclosure" que practican foros como "una-al-día", donde los detalles
de las vulnerabilidades se facilitan de forma pública. Si bien algunos
consideran que esta práctica es contraproducente, ya que la
información llega al mismo tiempo a los que intentarán defenderse
cómo a los atacantes potenciales, las ventajas son obvias: los
lectores pueden comprobar las vulnerabilidades en sus sistemas y
adoptar medidas preventivas, conocer los detalles permite estudiar
y detectar problemas similares y, por razones obvias, los
distribuidores se apresuran en corregir las vulnerabilidades y
facilitar parches a los usuarios.
La vulnerabilidad

El modelo de seguridad del estándar Java hasta JDK 1.1 prohibe
cualquier tipo de acceso a los ficheros locales del sistema. La
característica ECL introducida por Lotus en su máquina virtual es
más flexible al respecto, ofreciendo la posibilidad al usuario final
de aceptar o cancelar una acción cuando intenta acceder a un fichero
local, mediante la aparición de un cuadro de diálogo donde se puede
elegir "Execute" o "Cancel".

Cuando se invoca al método getSystemResource(String) de la clase
java.lang.ClassLoader, el cuadro de diálogo aparece *sólo* si existe
el fichero que se pasa como argumento. Si bien el método siempre
devuelve el valor "null" se haya elegido cualquier opción del cuadro
de díalogo o si este ni siquiera se ha visualizado, la diferencia de
tiempo que transcurre es distinta. Es decir, cuando el fichero no
existe el cuadro de diálogo no aparece, el valor "null" es devuelto
de forma instantánea y la aplicación sigue su curso. Sin embargo,
cuando el fichero existe aparece el cuadro de diálogo y el tiempo de
proceso es mayor, por lo que midiendo el tiempo que transcurre antes
y después de invocar al método se puede establecer si el fichero
existe o no.

Código:

long start = System.currentTimeMillis();
URL resource = ClassLoader.getSystemResource(filePathname);
long diff = System.currentTimeMillis() - start;
if (diff > 400) { [existe]
...
Implicaciones

A continuación algunos ejemplos de las posibilidades que ofrece la
explotación de esta vulnerabilidad:

-Conocer si el usuario ha visitado sitios web específicos, chequeando
la existencia de sus respectivas cookies.

-Saber si una dirección web se encuentra en la clasificación de
"favoritos" de Internet Explorer, chequeando la existencia del
correspondiente archivo en \WINDOWS\Favorites\.

-Descubrir si un fichero determinado ha sido utilizado recientemente,
chequeando la existencia de un acceso directo con el mismo nombre en
la carpeta \WINDOWS\Recent\.

-Conocer si hay determinadas aplicaciones instaladas o configuraciones
específicas del sistema, cuyo conocmiento puede ser aprovechado para
llevar a cabo otros ataques.
Demostración

Takagi ha creado un applet que demuestra, y permite a los usuarios
verificar, la existencia del agujero. El ejemplo, que funcionará de
forma correcta en Lotus Notes Client R5, comprueba si tenemos
instaladas determinadas aplicaciones chequeando la existencia de sus
trayectorias y ejecutables por defecto, así como informa si hemos
visitado el sitio web de PlayBoy tras examinar algunas cookies.



Bernardo Quintero
bernardo@hispasec.com


Más información:

Lotus Notes R5 Client
http://www.lotus.com/home.nsf/welcome/notes

Lotus Notes Client R5 File Existence Verification Vulnerability
http://www.securityfocus.com/bid/1994

Security Hole in ECL Feature of Java VM Embedded in Lotus Notes Client R5
http://java-house.etl.go.jp/ml/archive/j-h-b/038904.html

Demostración
http://java-house.etl.go.jp/~takagi/java/security/lotus-notes-existence-attack/Test.html



miércoles, 22 de noviembre de 2000

Ejecución de código arbitrario a través de "tmpwatch"

El programa "tmpwatch" permite que un usuario local ejecute código
arbitrario en el servidor, con los privilegios del usuario que lanza
"tmpwatch", típicamente "root".
"tmpwatch" es un programa que se encarga de eliminar ficheros
temporales que no han sido modificados o a los que no se haya accedido
en un determinado espacio de tiempo. Suele ser un comando utilizado en
directorios compartidos por varios usuarios (típicamente, "/tmp") y
liberar espacio en disco. Se trata, adicionalmente, de una herramienta
ejecutada típicamente por "root".

La versiones de "tmpwatch" anteriores a la 2.6.2 invocan el comando
"fuser" para identificar ficheros abiertos por otros procesos, pero
dicha invocación, a través de la función "system()", se realiza de
forma insegura: un usuario puede crear un fichero cuyo nombre contenga
metacaracteres shell y forzar la ejecución de comandos arbitrarios si
se lanza "tmpwatch" con la opción "-s" o "-fuser".

La vulnerabilidad afecta a las versiones 6.2 y 7.0 de Red Hat Linux, y
6.0, 6.1, 7.0 y 7.1 de Linux-Mandrake.

Adicionalmente, las versiones de "tmpwatch" en Red Hat Linux 6.1, 6.2
y 7.0, y 6.0, 6.1, 7.0 y 7.1 de Linux-mandrake, procesan los
directorios haciendo un "fork()" en cada uno de ellos, lo que puede
producir un ataque de denegación de servicio (por desbordamiento de la
tabla de procesos) si un usuario crea una jerarquía de directorios muy
profunda.

La recomendación es actualizar a la versión 2.6.2 de "tmpwatch".



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


Más información:

Insecure call of external programs in Red Hat Linux tmpwatch
http://xforce.iss.net/alerts/advise64.php

tmpwatch has a local denial of service and root exploit
http://www.redhat.com/support/errata/RHSA-2000-080-01.html

Linux-Mandrake Update and Security Advisories
http://www.linux-mandrake.com/en/security/



martes, 21 de noviembre de 2000

Actualización de seguridad en Windows MediaPlayer

Microsoft publica una actualización de seguridad para eliminar dos
vulnerabilidades en Windows Media Player debido a un desbordamiento de
búfer en archivos .ASX y ejecución de scripts .WMS.
Las nuevas vulnerabilidades descubiertas pueden ser empleados por un
usuario malicioso para lograr la ejecución de un programa de su
elección en otros ordenadores. Las dos vulnerabilidades son totalmente
independientes entre sí, excepto en que en ambas afectan al Windows
Media Player. Por este motivo, Microsoft las trata en el mismo boletín
de seguridad y propone la misma actualización para su corrección.

La primera de las vulnerabilidades hace referencia a un problema de
desbordamiento de búfer proveniente del soporte de archivos .ASX
(Active Stream Redirector), que permite a los usuarios la reproducción
de archivos multimedia que residen en la intranet o Internet. Sin
embargo, el código que interpreta estos archivos tiene un búfer sin
comprobar que puede permitir a un usuario malicioso la ejecución de
código en la máquina de otro usuario.

El usuario malicioso puede enviar un archivo afectado a otro usuario y
lograr que este lo visualice en su sistema, o bien, dejar el archivo
preparado en alguna página web y hacer que este se lance cada vez que
alguien acuda a visitar la página. El código podrá llegar a realizar
cualquier acción en la máquina del usuario bajo los permisos de este.

La vulnerabilidad de ejecución de scripts .WMS proviene de la
característica de Windows Media Player 7 de personalización mediante
el uso de "skins". Un skin .WMS puede incluir un script que se llegará
a ejecutar si se selcciona dicho skin para modificar el aspecto de
Windows Media Player. Como el código reside en el ordenador del propio
usuario atacado, el usuario malicioso podrá ejecutar controles ActiveX
incluyendo aquellos "no seguros para scripting". Esto permitirá al
código ejecutar cualquier acción a través de un control ActiveX.



Antonio Ropero
antonior@hispasec.com


Más información:

Actualizaciones para Windows Media Player 6.4
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=26069

Actualización para Windows Media Player 7
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=26067

Boletin de seguridad de Microsoft
http://www.microsoft.com/technet/security/bulletin/ms00-090.asp

Preguntas y respuestas sobre el boletin de seguridad
http://www.microsoft.com/technet/security/bulletin/fq00-090.asp



lunes, 20 de noviembre de 2000

"GnoRPM" escribe y sobreescribe ficheros arbitrarios

Las versiones anteriores a 0.95.1 de "GnoRPM" permiten que un usuario
local consiga escribir, y sobreescribir, ficheros arbitrarios, con
privilegios de otros usuarios, en particular "root".
"GnoRPM" es un gestor de paquetes RPM para entornos Gnome. Las
versiones previas a 0.95.1 hacen un uso inseguro de los ficheros
temporales, que puede ser aprovechado por otros usuarios locales del
sistema para "inyectar" sus propios ficheros durante una instalación
de un RPM por parte de otros usuarios, especialmente "root".

La nueva versión puede ocasionar problemas de compatibilidad en
algunas instalaciones Linux. Los detalles pueden encontrarse en los
avisos de seguridad de cada fabricante.



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


Más información:

Updated gnorpm packages are available for Red Hat Linux 6.1, 6.2, and 7.0
http://www.redhat.com/support/errata/RHSA-2000-072.html



domingo, 19 de noviembre de 2000

"boa" permite la lectura y ejecucion remota de forma arbitraria

Las versiones de "boa" anteriores a la 0.94.8.3 permiten que un
usuario remoto acceda a ficheros fuera del árbol de directorios de
"boa", construyendo una URL especialmente formateada. Los directorios
deben ser accesibles por el usuario que ejecuta "boa", típicamente
"nobody". También permite ejecutar comandos casi arbitrarios.
"boa" es un servidor web de altas prestaciones.

Las versiones vulnerables de "boa" no restringen adecuadamente la
peticiones URL que contienen ".." en el path, permitiendo el acceso a
ficheros arbitrarios que sean accesibles por el usuario que ejecuta
"boa", normalmente "nobody".

Asimismo, si "boa" se instala con soporte CGI, ejecutará cualquier
fichero cuya URL termine en ".cgi". Combinando esta vulnerabilidad con
la anterior, es posible ejecutar código arbitrario si el atacante
puede escribir en algún directorio del servidor. Esto es factible si
se trata de un usuario local o el servidor, por ejemplo, permite
acceso FTP con permisos de escritura.

La recomendación es actualizar a 0.94.8.3 o superior.



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


Más información:

boa: exposes contents of local files
http://www.debian.org/security/2000/20001009

boa web server allows arbitrary file access/execution
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-00%3A60.boa.asc



sábado, 18 de noviembre de 2000

Nuevo aviso de Guninski sobre ejecución de programas en IE y Outlook

Georgi Guninski, más que habitual en nuestro servicio de noticias,
publica un nuevo aviso de seguridad en el cual informa de la
posibilidad de IE 5.x y Outlook para ejecutar cualquier programa
mediante el uso de archivos .chm y la carpeta de archivos temporales
de Internet.
El propio Guninski ya anunció una vulnerabilidad similar con relación
a los archivos .chm, aunque en aquella ocasión Microsoft corrigió el
problema restringiendo la ejecución de archivos chm sólo si el fichero
se cargaba desde el sistema local de archivos. Pero es posible
encontrar la carpeta de archivos temporales de Internet, que pueden
ser múltiples carpetas con nombres aleatorios.

El siguiente código HTML:
<OBJECT DATA="http://ServidorWeb.com /chmtemp.html" TYPE="text/html"
WIDTH=200 HEIGHT=200>

Donde ServidorWeb.com es un servidor web o alias diferente del
servidor web desde el que se carga la página HTML puede revelar una de
las carpetas de archivos temporales de Internet a través del
documento.

Una vez que se conoce el nombre de una carpeta de archivos temporales
de Internet es posible almacenar un .chm en cualquiera de las carpetas
a tal efecto y tras ello emplear windows.showHelp() para ejecutarlo.
Existen otras forma de ejecutar programas una vez que una carpeta de
archivos temporales de Internet se conoce y el documento se guarda en
cache en ella, pero según Guninski showHelp() es el medio más sencillo
de llevar esto a cabo.



Antonio Ropero
antonior@hispasec.com


Más información:

Aviso de Georgi Guninski:
http://www.guninski.com/chmtemp-desc.html

Demostración del problema:
http://www.guninski.com/chmtempmain.html



viernes, 17 de noviembre de 2000

Desbordamiento de búfer en "cURL"

Las versiones de "cURL" previas a la 7.3 son vulnerables a un ataque
de desbordamiento de búfer que permite ejecutar código arbitrario en
el cliente.
"cURL" es una herramienta para descargar ficheros por Gopher, FTP y
HTTP.

Las versiones de "cURL" previas a la 7.3 contienen un desbordamiento
de búfer que permite tanto matar el cliente como ejecutar código
arbitrario en la máquina del usuario que está utilizando el programa.
El ataque debe realizarlo un servidor malicioso al que el usuario se
conecta con "cURL". El ataque es más factible de lo que pudiera
parecer, ya que se puede conseguir que un usuario acceda a un servidor
malicioso empleando técnicas de ingeniería social, spam, etc.
Pensemos, por ejemplo, en un mensaje en las "news" de Linux tipo
"descargate gratis el nuevo Apache Pro 4.0".

El problema se localiza en el módulo FTP, cuando se recibe un código
de error por parte del servidor.



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


Más información:

cURL
http://curl.haxx.se/

cURL Remote Buffer Overflow Vulnerability
http://www.securityfocus.com/bid/1804



jueves, 16 de noviembre de 2000

Fallos de seguridad en "dump" y "restore"

La versión 0.4b15 de "dump" y "restore" permite la ejecución de código
arbitrario como SETUID, típicamente como "root".
"dump" y "restore" son programas para la realización y recuperación de
copias de seguridad de discos duros, y están incluídos en la
distribución Linux de Red Hat. Las versiones previas a 0.4b16 permiten
la ejecución de código arbitrario SETUID, al invocar los programas
cuyos paths aparecen en las variables de entorno "RSH" y "TAPE".

La recomendación es actualizar a la versión 0.4b19 o superior.

En caso de no poder actualizar, y suponiendo que la máquina sea
accesible por usuarios maliciosos (se trata de un ataque local), es
posible eliminar el flag SETUID de "/sbin/dump" y "/sbin/restore".



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


Más información:

Dump/restore utilities
http://dump.sourceforge.net/

Multiple Linux Vendor dump Insecure Environment Variables Vulnerability
http://www.securityfocus.com/bid/1871

Red Hat 7.0 dump is being released for Red Hat 6.x and Red Hat 5.x
http://www.redhat.com/support/errata/RHSA-2000-100.html



miércoles, 15 de noviembre de 2000

Continúa la polémica con "Carnívoro"

El pasado jueves se realizó la segunda entrega de los documentos en
los que se describen las características técnicas de "Carnívoro",
el polémico programa de control de correo electrónico utilizado por el
FBI.
La utilización de este software ha vertido ríos de tinta postulando a
favor y en contra de la necesidad del control de las comunicaciones
con la finalidad de prevenir delitos por parte de los cuerpos
policiales.

Como ya informamos en su día, desde nuestro servicios de noticias, la
filtración de las características técnicas está siendo realizada
concienzudamente y realmente aporta poca claridad al funcionamiento y
las capacidades de monitorización de mensajes en los servidores del
mencionado software. La posibilidad de captura de (VOIP) voz a través
de redes IP parece ser otra potencial cualidad que tiene este
programa.

Igualmente se intenta desarrollar un sistema para proteger a Carnívoro
ante posibles ataques DoS.

De las 3000 páginas que se esperaban recibir con el fin de analizar
el polémico software, la realidad ha demostrado que tan sólo han
llegado menos de un millar de documentos a los investigadores
designados por el departamento de justicia. El propio FBI ha advertido
a los técnicos encargados del estudio de "Carnívoro", que únicamente
queda otra entrega de material para su estudio, que serán entregados
dentro de 45 días.

Entre algunas de las peculiaridades de Carnívoro se ha conocido que
no es un único software sino que se compone de diferentes programas
incluidos en un mismo paquete. Si hacemos un poco de historia podemos
comentar que "Carnívoro" es la continuación de otro programa
desarrollado con la misma finalidad por el FBI denominado "Omnívoro",
este fue creado originalmente a principios del año 1997 para
plataformas Sun Solaris x86. Omnívoro se quedó en el olvido, pero
fue reemplazado por "Carnívoro", desarrollado para plataformas NT.



Antonio Román Arrebola
antonio_roman@hispasec.com


Más información:

EPIC: Carnivore not as selective as FBI said:
http://www.infoworld.com/articles/hn/xml/00/11/17/001117hncarnivore.xml?p=br&s=2

Carnivore review due Friday:
http://www.theregister.co.uk/content/1/14820.html

Trabas para analizar a "Carnívoro":
http://www.hispasec.com/unaaldia.asp?id=688

El FBI obligado a descubrir a "Carnívoro":
http://www.hispasec.com/unaaldia.asp?id=666



martes, 14 de noviembre de 2000

"OpenSSH" vulnerable a servidores maliciosos

Las versiones de "OpenSSH" anteriores a la 2.3.0 son susceptibles a un
ataque proveniente de un servidor malicioso al que estén conectados.
"OpenSSH" es una implementación "Open Source" de SSH. SSH es "Secure
SHell", un sistema de acceso shell (como telnet) que utiliza
protocolos criptográficos para verificar la identidad de ambas partes
y para proteger la comunicación en sí.

Las versiones anteriores a la 2.3.0 permiten que un servidor malicioso
canalice peticiones X11 (X-window) y peticiones "ssh-agent" hacia el
cliente, incluso en el caso de que se haya configurado para no
negociar dichas funcionalidades durante la conexión.

En dicho caso, el cliente rechazará la negociación de dichas
capacidades durante la conexión, correctamente. Pero el problema es
que aceptará peticiones de ese tipo provenientes del servidor, si éste
se las hace llegar. Para ello el servidor debe ser modificado para
ignorar el rechazo de estas funcionalidades que el cliente le indicó
durante la negociación inicial.

Se recomienda a todos los usuarios de "OpenSSH" que actualicen a la
versión 2.3.0 o superior, sobre todo si utilizan el protocolo SSH para
conectarse a servidores administrados por entidades fuera de su
control.



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


Más información:

OpenSSH
http://www.openssh.com/



lunes, 13 de noviembre de 2000

Acceso "root" desde "modutils"

Las versiones de "modutils" anteriores a la 2.3.21 son susceptibles a
un ataque por parte de un usuario local, que le permite ejecutar
código como "root".
"modutils" son unas utilidades Linux para la gestión y carga de
módulos kernel: drivers de dispositivos, sistemas de ficheros, módulos
criptográficos, etc.



Las versiones de "modutils" anteriores a 2.3.21 permiten que un
usuario local ejecute código como "root". El fallo afecta a módulos
que aceptan datos bajo el control del usuario como base para llamadas
"request_module()". La vulnerabilidad se localiza en la utilidad
"modprobe", que es la responsable de cargar módulos nuevos,
concretamente en su sistema de expansión de argumentos.

Parece que el bug fue introducido en Marzo de 1.999. Las versiones
anteriores a dicha fecha no son vulnerables (la versión 2.1.121, por
ejemplo).

La versión 2.3.11 tampoco parece que sea vulnerable.

Tanto SuSE como Red Hat han publicado ya parches para esta
vulnerabilidad. En el momento de escribir este boletín sus respectivas
páginas web no estaban actualizadas, pero se puede acceder a los
boletines y los parches a través del enlace que se lista al final de
este documento.



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


Más información:

Linux modprobe Arbitrary Command Execution Vulnerability
http://www.securityfocus.com/bid/1936



domingo, 12 de noviembre de 2000

Desbordamiento de búfer en el login de Windows NT Terminal Server

Microsoft ha publicado un parche destinado a eliminar una
vulnerabilidad en Windows NT 4.0 Terminal Server. El problema
descubierto puede permitir que un atacante provoque un bloqueo del
ordenador o incluso la ejecución de código malicioso en el servidor.
Un búfer sin comprobar en el campo de usuario en el prompt del login
de Terminal Server puede permitir a un usuario malicioso la
posibilidad de ejecutar código arbitrario en el servidor. Este riesgo
podrá brindar la oportunidad de añadir, modificar o borrar datos del
servidor. Para iniciar este ataque no es necesario que el usuario
conozca un nombre y password válidos en el sistema.

Si las peticiones de conexión no se filtran de forma adecuada es
posible incluso lograr la realización de este ataque de forma remota.
Por defecto, Terminal Server escucha en el puerto tcp 3389. Este
puerto debe ser bloqueado a nivel del firewall o router si no se
requiere acceso al servidor de terminales desde Internet.

El parche necesario para evitar esta vulnerabilidad se encuentra
disponible en:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25565



Antonio Ropero
antonior@hispasec.com


Más información:

Boletín de seguridad Microsoft MS00-087:
http://www.microsoft.com/technet/security/bulletin/ms00-087.asp

Respuestas a las preguntas más frecuentes:
http://www.microsoft.com/technet/security/bulletin/fq00-087.asp

Aviso de seguridad de CORE-SDI:
http://www.core-sdi.com/advisories/win_nt.htm



sábado, 11 de noviembre de 2000

Divulgación de contenidos de memoria en servidores RealServer

RealServer es el servidor de distribución de contenidos de audio o
vídeo a través de Internet que luego pueden ser reproducidos en tiempo
real con el RealPlayer. Un problema existente tras la instalación de
este programa puede brindar a un atacante información que le permita
obtener acceso administrativo al servidor o datos pertenecientes a las
sesiones de otros usuarios.
Se ha descubierto una vulnerabilidad de divulgación de contenidos de
memoria en el conocido RealServer de RealNetworks, lo cual puede
ofrecer información sobre la configuración del servidor, datos de la
memoria en tiempo de ejecución y credenciales de autentificación. Esta
información puede permitir a un atacante remoto obtener la información
necesaria para conseguir acceder al servidor o datos de otros
usuarios.

Como siempre el problema se agrava debido a la facilidad con que se
puede obtener esta información, simplemente con acceder a la dirección
http://Servidor_vulnerable/admin/includes/ (es necesario incluir la
"/" final) se producirá una respuesta que contendrá partes aleatorias
del contenido en ejecución de la memoria.

Los datos obtenidos consisten generalmente en información de las
sesiones anteriores y contienen información que podría ser empleada
para obtener acceso no autorizado a detalles de la administración de
RealServer, como cookies enviadas a otros usuarios, nombres de
usuarios y passwords codificadas en BASE64, el puerto aleatorio donde
se encuentra la administración, etc.

Real.com ha publicado una actualización para Real Server que corrige
este problema y que puede encontrarse en
v, cuya
instalación se recomienda a todos los administradores de este
servicio.



Antonio Ropero
antonior@hispasec.com


Más información:

Real.com:
http://service.real.com/help/faq/security/memory.html

Bugtraq:
http://www.securityfocus.com/archive/1/145448

CORE-SDI:
http://www.core-sdi.com/advisories/real_server.htm



viernes, 10 de noviembre de 2000

Vulnerabilidad de denegación de servicio en Watchguard Firebox II

Watchguard Firebox II se ha convertido en una solución firewall basada
en hardware muy popular por su sencilla implementación dentro de
cualquier entorno de red. Se ha descubierto una vulnerabilidad para
este sistema que puede permitir a un atacante remoto lanzar un ataque
de denegación de servicio contra todos los servicios del firewall.
Si un usuario malicioso es capaz de conectar de forma remota con el
proxy ftp del firewall y lanzar un gran número de petición de
conexión, el proxy y el puerto sobre el que se ejecuta el servicio se
colgarán en el intento de procesar todas las peticiones. Esto tiene
como efecto secundario el bloqueo de todos los demás servicios del
firewall como la administración remota a través del puerto 4105.

Tras un ataque con éxito la utilización de la CPU alcanzará un 100% lo
que provoca el mencionado bloqueo de todos los servicio y hará
necesario reiniciar el firewall para restaurar su correcto
funcionamiento. Sin embargo, el filtrado y la actualización de reglas
dinámicas continuarán funcionando tras el ataque.

Hay que destacar que para que el ataque se realice con éxito el proxy
ftp debe estar habilitado sobre la interfaz no confiable ya que esta
configuración no viene activada por defecto.



Antonio Ropero
antonior@hispasec.com


Más información:

Bugtraq:
http://www.securityfocus.com/archive/1/145297

Securityfocus:
http://www.securityfocus.com/vdb/bottom.html?vid=1953



jueves, 9 de noviembre de 2000

Excesivos privilegios en la cuenta por defecto de Exchange 2000

Exchange 2000 es la aplicación de mensajería y trabajo en grupo de
Microsoft diseñada específicamente para su funcionamiento bajo Windows
2000. Esta vulnerabilidad hace referencia a la asignación inadecuada
de permisos en la cuenta de usuario por defecto de Exchange 2000.
Durante el proceso se instalación de Exchange 2000 Server se crea de
forma automática la cuenta de usuario EUSR_EXSTOREEVENT. A esta cuenta
se le asigna una compleja password generada de forma automática por el
sistema, y el nivel de permisos o privilegios asignados a esta cuenta
dependerá del tipo de servidor sobre el que se instale Exchange. Si
Exchange se instala sobre un servidor independiente EUSR_EXSTOREEVENT
tendrá los permisos equivalentes a un usuario local normal. Sin
embargo, si la instalación se realiza sobre un controlador de dominio
dicha cuenta poseerá los derechos de un usuario del dominio lo cual
hace aumentar el posible impacto que pudiera tener el acceso a ella
por un usuario malicioso. Ya que en tal caso el intruso podrá
reproducir sus acciones a lo largo de todo el dominio.

No se trata de una vulnerabilidad que pueda permitir el acceso al
servidor Exchange, sino del problema de seguridad que representa que
en caso de que un atacante consiga el acceso sobre dicho servidor
Exchange pudiera expandir su ataque sobre todo el dominio, lo cual ya
es extremadamente grave.

Para eliminar esta vulnerabilidad Microsoft proporciona un
procedimiento manual, aunque también incluirá la solución en el
Service Pack 1 para Exchange 2000. La solución manual indicada por
Microsoft para solucionar el problema pasa por la eliminación de la
cuenta EUSR_EXSTOREEVENT o modificar la passwotd si se encuentra en
uso.



Antonio Ropero
antonior@hispasec.com


Más información:

Securityfocus:
http://www.securityfocus.com/vdb/bottom.html?vid=1958

Boletin de Seguridad de Microsoft:
http://www.microsoft.com/technet/security/bulletin/ms00-088.asp

Prguntas y respuestas de Microsoft:
http://www.microsoft.com/technet/security/bulletin/fq00-088.asp

Utilidad de Micrososft para protección:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25866



miércoles, 8 de noviembre de 2000

Vulnerabilidad en el "crontab" de varios UNIX

La versión de "crontab" de varios UNIX permite que un usuario local
pueda leer cualquier archivo del sistema.
"Crontab" es una aplicación para proporcionar entradas a "cron".
"Cron" es un programa que permite la ejecución de tareas periódicas en
el sistema, y normalmente es accesible a todos los usuarios locales
(las tareas se ejecutarán con los privilegios de cada usuario, por
supuesto).

La versión actual del "crontab" de varios UNIX permite que un usuario
lea cualquier archivo del sistema. Para ello los pasos a seguir son:

- Invocar "crontab -e", para editar nuestras tareas actuales

- "Crontab" creará un fichero en "/var/tmp", que contendrá nuestras
entradas. El path del fichero en cuestión aparece en pantalla.

- Lanzamos un shell nuevo (desde el "vi" o desde otra sesión) y
borramos dicho fichero temporal.

- Seguidamente creamos un enlace simbólico al fichero que queremos
leer, con el nombre del fichero temporal que hemos borrado.

- Volvemos a "crontab" y salimos del editor.

- El "crontab" nos mostrará el fichero que hayamos indicado,
entremezclado con mensajes de error. El fichero es perfectamente
recuperable a partir de ese listado.

Que se sepa, la situación actual es la que sigue:

* Versiones vulnerables:

HP-UX 10.20
HP-UX 11.00
Tru64 4.0d sin parches
FreeBSD 2.2.8 (*)
FreeBSD 3.3 (*)
FreeBSD 4.0 - Release #9 (*)
FreeBSD 4.1 - Release #1 (*)

(*) Requiere que las lineas del fichero a leer empiecen con "#".

* Versiones *NO* vulnerables:

AIX 4.2
Linux SlackWare 4.0
Linux SlackWare 7.0
Solaris 2.5.1
Tru64 4.0d con parches recomendados
Tru64 4.0f y superior



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


Más información:

HP-UX crontab /tmp File Vulnerability
http://www.securityfocus.com/bid/1845



martes, 7 de noviembre de 2000

Verificación incorrecta de firmas en GNUPG

Las versiones de GNUPG previas a la 1.0.4 contienen un error de
programación que puede ocasionar que el programa informe de que las
firmas son correctas cuando algunas de ellas son, en realidad,
inválidas. Este problema sólo afecta a ficheros con múltiples firmas.
GNUPG (GNU Privacy Guard) es un reemplazo del conocido PGP (Pretty
Good Privacy). Se trata de un programa para cifrar y firmar (y sus
operaciones inversas) documentos, tanto en forma de ficheros como de
correo electrónico.

Las versiones previas a 1.0.4 sólo verifican la primera firma de un
archivo, por lo que si alguna otra firma falla, el archivo se
considerará válido de todas formas.

Se recomienda que todos los usuarios actualicen a GNUPG 1.0.4 o
superior, cuanto antes.



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


Más información:

The GNU Privacy Guard
http://www.gnupg.org/



lunes, 6 de noviembre de 2000

Ataque de denegación de servicio sobre BIND 8.2.2-P5 y previas

La versión 8.2.2-P5 de BIND, la actual hasta el momento, posibilita un
ataque de denegación de servicio que permite matar al servidor BIND.
El problema afecta a todos los BIND 8.2.2 hasta P6.
El servidor BIND es el servidor de nombres DNS más popular de
Internet, y está desplegado en millones de máquinas en todo el mundo.
Como servidor de nombres, BIND es el responsable de proporcionar una
dirección IP a partir de un nombre de máquina, y viceversa. Por tanto,
su uso es constante y masivo.

Las versiones 8.2.2-P5 y previas del servidor BIND mueren cuando un
atacante intenta realizar una transferencia de zona empleando
compresión en el enlace, y el servidor se ha compilado sin soporte
para dicha transacción (situación que se dá por defecto).

El ataque puede ser ejecutado por cualquier atacante malicioso, si el
servidor de nombres víctima no impone restricciones a las IPs a las
que se permite solicitar una transferencia de zona, lo que resulta
bastante habitual.

En caso de que el servidor de nombres víctima se haya configurado para
aceptar peticiones de transferencia de zona solo desde determinadas
IPs, el ataque deberá realizarse desde alguna de esas máquinas. Si los
servidores secundarios son confiables, configurar adecuadamente el
servidor BIND para que sólo acepte peticiones de transferencia de zona
desde ellos puede ser una solución temporal mientras no se actualiza
el servidor.

Se recomienda que todos los usuarios de BIND 8.2.2 actualicen cuanto
antes a la versión 8.2.2-P7, disponible en estos momentos. La nueva
versión corrige también un problema con bucles infinitos al
decodificar una respuesta DNS especialmente formateada, y otros
problemas menores.



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


Más información:

BIND
http://www.isc.org/products/BIND/

BIND Vulnerabilities
http://www.isc.org/products/BIND/bind-security.html



domingo, 5 de noviembre de 2000

Llegan los virus que se aprovechan de la Navidad

Aunque todavía estamos en noviembre la Navidad está próxima y como tal
son clásicas las felicitaciones vía correo electrónico, medio empleado
por los virus para reproducirse. Todavía se recuerdan los efectos y
propagación de Happy99, en esta ocasión se ha detectado la propagación
de W32/Navidad.
W32/Navidad es un nuevo gusano que se distribuye a través del correo
electrónico, este virus ya ha empezado a reproducirse en Sudamérica y
Estados Unidos. El gusano llega al usuario en forma de e-mail con un
archivo adjunto con el nombre NAVIDAD.EXE, y ya se encuentra "in the
wild" aunque su riesgo a sido evaluado como medio. Pero debido a su
nombre español no dudamos de que llegará a nuestro país en breve.

La parte vírica del mensaje reside precisamente en el archivo adjunto
NAVIDAD.EXE que no deberá ser ejecutado bajo ningún concepto. Si se
llega a ejecutar mostrará una ventana de error con el texto "UI" tras
esto un icono de un ojo azul aparecerá en los iconos del sistema junto
al reloj, en la esquina inferior derecha de la pantalla. El gusano
grabará una copia de si mismo en el directorio System de Windows bajo
los nombres WINSVRC.VXD y WINSVRC.EXE y creará las siguientes claves
en el registro:

HKEY_CURRENT_USER\SOFTWARE\Navidad

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\
Win32BaseServiceMOD=C:\WINDOWS\SYSTEM\winsvrc.exe

HKEY_CLASSES_ROOT\exefile\shell\open\command\
(default)=C:\WINDOWS\SYSTEM\winsvrc.exe "%1" %*

HKEY_LOCAL MACHINE\Software\CLASSES\exefile\shell\open\command\
(default)=C:\WINDOWS\SYSTEM\winsvrc.exe "%1" %*

En esta última entrada su acción consistirá en modificar su valor
original "%1" %* .

Para eliminar el gusano de los sistemas afectados será necesario
eliminar las claves creadas en el registro y restaurar el valor
original de la clave modificada por el virus. Para ejecutar el editor
del registro (regedit.exe) será necesario crear una copia como
regedit.com ya que debido a un error de programación el sistema será
incapaz de ejecutar ningún programa de extensión .EXE.

Como hemos mencionado tras ejecutar el gusano se evidenciará la
presencia de un icono con un ojo, al situar el cursor sobre el icono,
se mostrará el mensaje "Lo estamos mirando...". Al pulsar sobre el
icono aparecerá un botón con el texto "Nunca presionar este botón". Si
se presiona el botón aparecerá una ventana titulada "Feliz Navidad",
con el mensaje "Lamentablemente cayo en la tentación y perdió su
computadora".

A pesar del aviso el programa no destruye nada en el ordenador del
usuario afectado, aunque las modificaciones que realiza en el registro
impiden que el sistema pueda ejecutar archivos de extensión .EXE.

El virus se reproduce al responder de forma automática a todos los
mensajes con archivos adjuntos que llegan al buzón de Inbox del
usuario afectado. Para ello hace uso del MAPI de Microsoft Outlook al
igual que trabajaban otros gusanos como LoveLetter o Melissa. La
respuesta generada consistirá en el mismo asunto y cuerpo pero con el
archivo NAVIDAD.EXE como adjunto.

Desde Hispasec queremos aprovechar esta oportunidad para recordar el
peligro de abrir o ejecutar archivos que se reciben adjuntos sin
conocimiento de lo que realmente consisten.



Antonio Ropero
antonior@hispasec.com


Más información:

McAfee:
http://vil.mcafee.com/dispVirus.asp?virus_k=98881&

Sybari:
http://www.sybari.com./alerts/alertdetail.asp?Name=W32/Navidad

Symantec:
http://www.symantec.com/avcenter/venc/data/w32.navidad.html

Panda Software:
http://www.pandasoftware.es/enciclopedia/gusano/W32Navidad_1.htm



sábado, 4 de noviembre de 2000

Entrevista a unos de los autores de Rijndael

Como nuestros lectores recordarán, a principios de Octubre el NIST
hizo pública su decisión respecto al AES, el algoritmo que debía
suceder al antediluviano DES hasta bien entrado el milenio. Para
sorpresa de muchos, el algoritmo elegido fue propuesto por dos
criptólogos belgas y tiene un nombre más bien impronunciable: Rijndael.
La revista online PlanetIT nos ofrece una entrevista con uno de los
autores de este algoritmo.
Vincent Rijmen desvela en la entrevista algunos de los entresijos y de
las variables consideradas durante el diseño de Rijndael, así como su
opinión sobre la criptografía en general.

Vincent comenta, por ejemplo, que la criptografía ha estado
tradicionalmente vinculada a mensajes de importancia transcendental
por lo que, entre otras cosas, la interceptación de un mensaje cifrado
despierta sospechas. Una solución para ello sería cifrar todas las
comunicaciones, independientemente de su importancia. La idea es la
misma que con el correo postal: aunque la mayoría de nuestras
comunicaciones postales podrían ir desprotegidas como "postales",
todos nosotros enviamos cartas en sobres cerrados, independientemente
de que lo que digamos en ellas sea o no importante.

Vincent detalla también, muy someramente, la estructura paralelizable
de Rijndael, comparándola con estructuras más clásicas y más probadas
pero cuya implementación es serial por definición, como las
estructuras "Feistel". Vincent también defiende el enfoque sencillo de
Rijndael, comparados con buena parte de sus competidores, desde la
perspectiva de que la sencillez posibilita un análisis más detallado y
preciso, y que no se ha demostrado que un enfoque deliberadamente más
complicado sea necesariamente más seguro.

La experiencia, de hecho, suele demostrar lo contrario.



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


Más información:

Interview: Rijndael´s Vincent Rijmen
The author of DES successor algorithm speaks out
http://www.planetit.com/techcenters/docs/security/qa/PIT20001106S0015

El criptosistema AES acaba de nacer
http://www.hispasec.com/unaaldia.asp?id=708
http://www.argo.es/~jcea/artic/hispasec96.htm



viernes, 3 de noviembre de 2000

Tres versiones nuevas del "Secure Hash Standard"

Casi coincidiendo con la aprobación del nuevo AES, el NIST americano
ha propuesto tres nuevos algoritmos de HASH, de 256, 384 y 512 bits.
Dichos algoritmos, todavía en fase de propuesta, amplian los 160 bits
actuales del SHA-1. Esta mayor longitud permitirá utilizar estos
algoritmos con el nuevo AES, y proporcionan una mayor protección
contra colisiones y el "ataque del cumpleaños".
Las especificaciones técnicas de los algoritmos están disponibles en
una página del gobierno norteamericano, con fines de evaluación e
informativos, antes de la propuesta formal como estándar, en el 2001.

Los algoritmos HASH toman una entrada de longitud arbitraria y
calculan un valor de tamaño fijo (de 128, 160 o los nuevos 256, 384 y
512 bits), cumpliendo una serie de propiedades criptográficas como:

* Conociendo un HASH, no obtenemos ninguna información sobre el
documento original.

* Teniendo un HASH dado, no es factible encontrar un documento cuyo
HASH coincida con el primero. Otra regla más fuerte dice que no debe
ser factible encontrar dos documentos cualesquiera cuyo HASH
coincida.

* Un cambio cualquiera en el documento de entrada debe modificar, en
media, la mitad de los bits de la salida.

Una de las quejas de la comunidad criptográfica es que en la
documentación del NIST se incluyen pocos "vectores de prueba", por lo
que es posible que implementaciones paralelas cumplan dichos vectores
a pesar de contener errores de programación. Otra de las quejas
generalizadas que se ha podido leer es el hecho de que el SHA-256
propuesto es más de tres veces más lento que el actual SHA-1 (SHA-160).
Por lo que parece, los algoritmos de HASH son cada vez más lentos,
mientras que los algoritmos de cifrado cada día son más rápidos...

Algunas informaciones señalan el hecho de que esa pérdida de
rendimiento está ocasionada, en buena medida, por los pocos registros
disponibles en los procesadores x86, aunque todavía no he visto datos
cuantitativos que avalen esta opinión. No hay que olvidar, asimismo,
que las implementaciones actuales son muy preliminares.

Una última queja de buena parte de la comunidad es el hecho de que no
se haya requerido a un concurso público para los nuevos SHA-2, como se
hizo con AES. Es posible que el resultado fuese un estándar bastante
más rápido y más avanzado tecnológicamente.



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


Más información:

Secure Hash Standard (SHS)
(SHA-1 Algorithm)
http://csrc.nist.gov/cryptval/shs.html

El criptosistema AES acaba de nacer
http://www.hispasec.com/unaaldia.asp?id=708
http://www.argo.es/~jcea/artic/hispasec96.htm

SHA-256/384/512 at www.AaronGifford.com
An open source implementation of the SHA-256, SHA-384, and SHA-512
secure hash algorithms in C
http://www.aarongifford.com/computers/sha.html



jueves, 2 de noviembre de 2000

Fraudes punto com

¿Quién no ha oído contar la vieja historia del cateto que vendía
estampitas verdes al precio de veinte duros? Los ojos de la víctima a
la que se los ofrecía enseguida se metamorfoseaban en $$$, como los
del tío Gilito. Claro que luego venía el tirarse de pelos y rasgar de
vestiduras cuando descubría que lo que parecían billetes de mil eran
en realidad recortes de periódico.
Mucho ha llovido desde entonces, pero lo cierto es que nuevos timos y
fraudes y transposiciones a Internet de otros muy antiguos continúan
perpetrándose al amparo de la gran red de redes. Los timadores del
fin de milenio ya no se disfrazan de baturros ni llaman a los timbres
de puerta en puerta, en busca de ancianitas ingenuas y de buen
corazón. No, qué va. Los timadores de hoy en día pueden dirigir
grandes compañías, estar al frente de pequeñas empresas o tratarse de
ladronzuelos de poca monta aunque con elevados conocimientos
tecnológicos. Eso sí, todos comparten una cierta astucia y falta de
escrúpulos. Las víctimas ya no son unas pocas abuelitas, sino
millones de internautas, a menudo con buena formación y cultura.

La Comisión Federal de Comercio (FTC) de EEUU ha decidido tomar
cartas en el asunto y legislar en esta materia para proteger al
incauto navegante. Nada mejor para abonar el terreno de un fértil y
productivo comercio electrónico que sentar las bases de una red
segura y a salvo de estafadores. La acción conjunta emprendida por la
FTC, Justicia, la industria y asociaciones de consumidores persigue
la creación de un clima propicio para el desarrollo sin trabas de la
nueva economía digital. Con este fin, pretende crear una red
internacional de agencias de protección al consumidor.

Recientemente, el 31 de octubre, y como parte de sus acciones en la
lucha contra el fraude en Internet, la FTC ha publicado un informe
sobre las diez estafas más frecuentes (www.ftc.gov/dotcons),
basándose en los datos recogidos en una lista de más de 285.000
quejas de consumidores. El objetivo de la publicación de este "Top
10" reside en informar a los consumidores de cuáles son estos timos y
qué deben hacer para no ser engañados. En concreto, las diez quejas
más frecuentes de los consumidores son las siguientes:

Fraude en subastas: después de enviar su dinero, recibe un producto
de menor valor que el prometido o de ningún valor en absoluto.

Timos de Proveedores de Servicio de Internet: puede encontrarse
atrapado en un contrato de larga duración para acceso a Internet, con
graves penalizaciones por rescisión anticipada.

Diseño/Promociones de sitios web: recibe cargos en su factura de
teléfono por servicios que nunca ha aceptado ni solicitado.

Abuso de tarjetas de crédito: se le solicita su número de tarjeta de
crédito exclusivamente para verificar su edad y luego se le pasan
cargos difíciles de cancelar.

Marketing Multinivel/Timos de pirámides: se le promete hacer dinero a
través de productos y servicios que usted mismo venderá, así como a
través de los vendidos por gente que usted reclute. A la hora de la
verdad, resulta que sus clientes son otros distribuidores, no el
público, y sus beneficios se evaporan.

Oportunidades de Negocio y Timos "Trabaje desde casa": se le promete
el oro y el moro en un negocio del que usted será su propio jefe,
ganando cantidades fabulosas de dinero. Por supuesto, después de que
invierta sus ahorros en esta maravillosa oportunidad de negocio,
resulta que todo era humo.

Esquemas de inversión y Timos tipo Hágase Rico Rápidamente: puede
perder su dinero confiando en programas o servicios que supuestamente
predicen la evolución del mercado con una precisión del 100%.

Fraude en Viajes/Vacaciones: compañías fraudulentas le mienten
respecto a sus paquetes de viajes, ofreciéndole alojamiento y
servicios de inferior calidad a la pagada, o le cargan por conceptos
que no aparecían en el contrato.

Fraudes telefónicos: sin que usted lo sospeche, mientras ve toneladas
de fotos y vídeos porno utilizando ese programa que debe instalar en
su ordenador, el módem se desconecta silenciosamente y marca un
número internacional, para acceder a Internet a través de un ISP en
el extranjero. Ni que decir tiene, la factura de teléfono será
astronómica.

Fraudes de Atención Sanitaria: ¿Que sufre una enfermedad incurable?
No se preocupe, aceite de serpiente a la venta a módico precio que
curará ésta y cualquier otra dolencia incurable.

Como se ve, muchos de estos fraudes no están pergeñados por chorizos
con conexión a Internet, sino por grandes compañías, como Telefónica:
el timo del ADSL (demoras en la instalación, cortes, velocidad
inferior a la esperada, precios abusivos, mala atención al cliente,
escasez de técnicos cualificados, reclamaciones inhumadas en el
silencio administrativo), el timo anterior de InfoVía (cortes, cobro
por llamadas fallidas, etc.), cobros en facturas de servicios nunca
solicitados, como llamada a tres o desvío inmediato de llamadas, que
mientras el cliente no rechiste se los cobran, al módico precio de
200 pesetas al bimestre, ... En fin, qué les voy a contar.

Picardía, astucia, descaro... Hay timos, como los de Telefónica, con
los que no queda más remedio que comulgar. Veremos qué pasa con la
paulatina liberalización del mercado de telecomunicaciones. En otros
casos, no peque de beato, que tanta bula papal prometiendo porciones
de cielo a precio de saldo y avemaría no puede sino encerrar gato
muerto.

En su mayor parte, los timos y fraudes explotan la ingenuidad y buena
fe de las víctimas y también su codicia. El afán por hacer dinero
fácil o encontrar chollos puede perder a más de uno. Si parece
demasiado bueno para ser verdad, no lo dude, no es verdad. Desconfiar
de la palabra GRATIS y de los precios increíbles, huir de compañías
con las que no existe ningún otro medio de contacto además de una
página web y nunca instalar programas sospechosos para obtener
contenidos gratuitos son normas básicas para evitar el fraude. Más
vale comprar en comercios de reconocido prestigio que aventurarse a
adquirir chollos sin garantía alguna. Nadie vende duros a cuatro
pesetas, y menos en los tiempos que corren.



Gonzalo Álvarez Marañón
criptonomicon@iec.csic.es


Más información:

Vídeo sobre CiberTimos
http://www.msnbc.com/news/486010.asp?cp1=1

Criptonomicon
http://www.iec.csic.es/criptonomicon/



miércoles, 1 de noviembre de 2000

Nueva política del CERT

A principios del pasado Octubre, el CERT norteamericano hizo pública
su nueva política a la hora de difundir avisos de seguridad. En ella
se indica que los problemas de seguridad serán anunciados de forma
pública a los 45 días del aviso inicial, independientemente de que
existan o no soluciones por parte de los fabricantes.
El CERT fue creado en 1.988 por el gobierno americano, tras el
archiconocido ataque del "gusano de Morris" que -en aquel año-
contaminó el 10% de todas las máquinas conectadas a Internet. El fin
del CERT es servir de punto de coordinación entre usuarios y
fabricantes, recibiendo avisos de seguridad, informando a los
fabricantes y emitiendo boletines de seguridad una vez que se disponía
de una solución o un parche.

La necesidad de disponer de soluciones antes de difundir un aviso de
seguridad de forma pública suponía que, en muchos casos, los avisos
del CERT llegaban muy tarde y, desde luego, mucho después de que se
conociese el problema por otros medios (por ejemplo, a través de
"una-al-dia"). Por otra parte, el propio CERT reconoce que en
numerosas ocasiones la única manera de forzar a los fabricantes a
elaborar un parche para un problema de seguridad es presionarlos
haciendo público dicho problema.

Debido a estos hechos, y a que dicha información estará disponible de
todas maneras a través de otros medios, la nueva política del CERT
indica que se publicarán boletines incluso en los casos en que algún
fabricante no haya solucionado el problema. Los fabricantes serán
informados desde el primer momento, y se les integrará en el proceso,
pero no se retrasará ningún aviso de forma indefinida por la falta de
diligencia de ningún vendedor.



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


Más información:

CERT
http://www.cert.org/

The CERT® Coordination Center Vulnerability Disclosure Policy
http://www.cert.org/faq/vuldisclosurepolicy.html