domingo, 30 de abril de 2000

Nueva vulnerabilidad en NetBIOS de Windows 9x

Muchos usuarios recordarán el clásico ataque de denegación de
servicios a Windows 9x que a través del NetBIOS causaba la temida
pantalla azul y el bloqueo de la máquina. Cuando ese problema parecía
estar superado se ha encontrado una nueva vulnerabilidad que de forma
similar puede causar un gran número de problemas a los usuarios.
Uno de los ataques más populares, conocido en muchos sitios como
WinNuke o ataque OOB (Out Of Band), se basaba en un fallo de la
interfaz NetBIOS de Windows incapaz de soportar datos "Out Of Band"
en el puerto TCP 139. Ya existen numerosos parches para esta
vulnerabilidad, tanto para Windows 9x, como para Windows NT. Pero
ahora surge un nuevo ataque, que también mediante una conexión NetBIOS
puede colgar o dejar sin conexión de red a todas las máquinas Windows
9x.

El problema surge cuando una sistema Windows 95/98 recibe un paquete
de una sesión NetBIOS con el nombre de la máquina fuente modificado a
NULL. La respuesta puede ser impredecible y muy variable, bloqueos,
reinicios, el "clásico" pantallazo azul o la pérdida total de conexión
a la red.

Según afirman los descubridores del problema, la vulnerabilidad se ha
encontrado a través de practicar ingeniería inversa a un programa ya
distribuido por la red (se ha encontrado "in the wild"), que bajo el
nombre de "whisper" realiza las acciones comentadas. A partir del
análisis de esta herramienta se ha conseguido averiguar la causa del
problema y elaborar un código abierto que lo reproduce.

Más información:
Securityfocus
Bugtraq



Antonio Ropero
antonior@hispasec.com



sábado, 29 de abril de 2000

Vulnerabilidades en FileMaker Pro 5.0

La propia desarrolladora del popular software de base de datos
FileMaker Pro 5.0 ha reconocido la existencia de vulnerabilidades en
el elemento Web Companion, por el cual cualquier usuario puede
examinar las bases de datos de otros usuarios así como falsear
e-mails.
El software Web Companion es una parte del paquete de base de datos
FileMaker Pro 5.0 (tanto para MacOS como para Windows NT), que incluye
capacidades de publicación XML pero en las cuales no se hace uso de
las características de seguridad web de FileMaker. De esta forma
cualquier usuario remoto puede consultar, vía XML, cualquier dato de
una página web conectada a una base de datos, independientemente de la
configuración de seguridad web de dichos datos.

FileMaker Pro 5.0 también integra soporte e-mail en las aplicaciones
web creadas a partir de bases de datos. Una de las características es
la capacidad de especificar los contenidos de un campo de una base de
datos para formar con ellos un mensaje. Esta característica evita la
seguridad web habitual de FileMaker Pro y permite a cualquier usuario
web remoto enviar cualquier contenido de una base de datos a una
dirección de correo independientemente de la configuración de
seguridad de dichos datos. Las características de email mencionadas
también permiten a los usuarios web enviar mensajes falsos de forma
anónima.

La propia compañía desarrolladora ha reconocido el problema y afirma
trabajar para poder ofrecer un parche que solucione los problemas lo
más rápido posible. Entre tanto se recomiendan configuraciones de
seguridad alternativas, como activar la protección por password, pues
el nivel de seguridad de los campos no es confiable.

Más información:
Securityfocus
Aviso Blue World
ZDNet
FileMaker



Antonio Ropero
antonior@hispasec.com



viernes, 28 de abril de 2000

El contraespionaje británico se prepara para monitorizar Internet

Poco a poco los servicios de inteligencia de los países mas avanzados
se van quitando la mascara y con la excusa de salvaguardar nuestras
libertades, suben el siguiente escalón para controlar aún mas nuestros
movimientos.
Hace un par de meses supimos que el recientemente creado servicio de
inteligencia ruso tenía un plan para obligar a los proveedores de
Internet de su país a instalar un software especifico con el fin de
controlar los movimientos de sus ciudadanos por la Red.

Este paso resultó indigno a todo el mundo concienciado con la libertad
de expresión, pero se pudo "comprender" porque venía de un país con
antecedentes poco democráticos muy recientes. Pero que pretexto se le
puede dar a la inversión de mas de 7000 millones de pesetas que hará
el gobierno de Gran Bretaña para construir un centro de control
denominado "GTAC".

Una ley obligará a los ISP´s británicos a mantener una conexión
directa por cable entre proveedores y el nuevo centro del famoso MI5,
de su Graciosa Majestad. Este nuevo centro tendrá medios y cobertura
legal para interceptar mensajes cifrados y posteriormente
descifrarlos, podrá incluso llegar a exigir a empresas y particulares
las claves necesarias con el fin de facilitar su "tarea".

El ministro británico encargado de desarrollar el proyecto, Charles
Clark, declaró que esta iniciativa dará una mayor tranquilidad
tecnológica a la policía. Esta iniciativa dada a conocer por el diario
The Sunday Times, espera aún al consentimiento por parte del
Ministerio de Interior británico. Entre todo este maremagnum de redes
de espionaje instauradas por el bien común, se hace una luz de parte
de las asociaciones civiles, que no están de acuerdo con este tipo de
políticas coactivas y que pretenden formar un frente común para
proteger el derecho a la intimidad de todos y cada uno de los
ciudadanos del mundo.

Más información:

El Mundo
The Times
Hispasec
Hispasec
Free, Fronteras Electrónicas




Antonio Ropero
antonior@hispasec.com



jueves, 27 de abril de 2000

Intel no incluirá más números de serie en sus procesadores

Tras la polémica inclusión de números identificativos en los
procesadores Pentium III Intel ha decidido eliminar el número de serie
en su próxima familia de procesadores.
Durante el pasado la polémica de la inclusión de un número de serie en
los procesadores Pentium III saltó a la luz. Este número conocido como
PSN (Pentium Serial Number) ofrecía la posibilidad de acceder a él
desde las aplicaciones e, incluso, desde Internet. Intel justificaba
dicha inclusión alegando su utilidad para las transacciones
electrónicas, ya que así les dotaba una mayor seguridad.

Pero este número identificativo no resultó del agrado de una gran
parte de los usuarios, así como de los defensores de la privacidad en
Internet. En sus argumentaciones se exponía la posibilidad que tendría
cualquier administrador para acceder a dicho valor.

Intel ha anunciado su decisión de eliminar este número en sus
procesadores, comenzando con el Willamette, el próximo chip de la
compañía que saldrá al mercado a finales de año. La compañía argumenta
su decisión en base al avance de las tecnologías de firmado digital
que hacen innecesario el número serie, si bien esté seguirá
incluyéndose en los procesadores Pentium III.

Más información:
Intel
ZDNet
Computerworld



Antonio Ropero
antonior@hispasec.com



miércoles, 26 de abril de 2000

Password secreta para acceder a servidores con el software Cart32

Se ha descubierto un agujero de seguridad de gran gravedad en el
software de comercio electrónico Cart32. La vulnerabilidad puede
definirse como una evidente puerta trasera basada en una password
secreta, por la cual un atacante podrá obtener el control total
del servidor y de las órdenes de compra.
El software de carro de compra Cart32 de McMurtrey/Whitaker &
Associates permite la creación de sitios web de comercio electrónico
bajo Win32, pero en el archivo principal del sistema (cart32.exe), el
encargado de ofrecer la funcionalidad de carrito de compra, se ha
encontrado una password secreta que puede emplearse para conseguir
información vital del sistema. De forma que un atacante puede
modificar las propiedades del carrito de compra así como acceder a los
detalles de las tarjetas de crédito de los usuarios, direcciones de
envío y todo tipo de información sensible.

Existen cientos de comercios electrónicos afectados que hacen uso de
Cart32, entre los que se incluyen Jazzworld.com, MusicWorld CD,
ComputerShop.com, Wirelesstoys.com, y ChocolateVault.com.

La contraseña se conoce de forma interna en el programa como
Cart32Password, y toma el valor de "wemilio" como puede verificarse en
el offset 0x6204h del archivo cart32.exe. A través de esta password un
atacante puede acceder a múltiples URLs no documentadas como
http://sistema_afetado/scripts/cart32.exe/cart32clientlist, lo que le
permitirá acceder a una lista de las passwords de cada tienda. Aunque
estas passwords aparecen cifradas pueden seguir siendo válidas, y
emplearse para crear una URL que permita al atacante obligar al
servidor a ejecutar un comando cuando se confirme un pedido.

Además de esto existe otra vulnerabilidad ya que se puede acudir
directamente a la URL
http://sistema_afectado/scripts/c32web.exe/ChangeAdminPassword y
modificar la password de administración sin necesidad de conocer la
anterior.

La compañía desarrolladora de Cart32 ha publicado los correspondientes
parches para evitar estas vulnerabilidades, si bien se ha visto
obligada a actuar de forma rápida al divulgarse la password de acceso,
ya que en un principió anunció que el parche estaría disponible lá
próxima semana. El anuncio de la publicación de los parches necesarios
con tanto retraso ha motivado un gran número de críticas, e incluso
compañías como L0pht han publicado parches alternativos. Por su parte
McMurtrey/Whitaker & Associates ha reconocido la existencia de la
puerta trasera, justificando su presencia para que los técnicos de la
empresa realizaran tareas de soporte cuando este era requerido.

Otra forma de eliminar el problema es editando el ejecutable con un
editor hexadecimal y modificar la password "wemilio" por otra palabra.
Por otra parte se hace recomendable asignar los permisos NTFS al
programa de administración c32web.exe de tal forma que sólo los
Administradores tengan acceso a él.

Más información:
Cart32
Parches
Parche de L0pht
Wired
Zdnet



Antonio Ropero
antonior@hispasec.com



martes, 25 de abril de 2000

Los peligros de los PSA

La última palabra de moda en los círculos Internet es ASP o PSA para
los españoles. A los veteranos de la programación web, ASP les
resultará familiar: Active Server Pages, la respuesta de Microsoft a
la creación dinámica de páginas web. Pero no, no se trata de ese ASP
sino de Application Service Providers o Proveedores de Servicios de
Aplicaciones (PSA).
¿Que no tiene dinero para comprar una aplicación de ERP o de CRM? No
se preocupe, un PSA es la respuesta. ¿Que no puede invertir tantos
recursos económicos y humanos en lanzar su aplicación de comercio
B2B? No se aflija, un PSA lo hace por usted. ¿Que sus servidores y
líneas de comunicación no pueden soportar el tráfico de la aplicación
que está proyectando? No hay problema, un PSA sí.

PSA representa la tendencia más novedosa en modelos de negocio
basados en Internet. Se fundamenta en ofrecer una solución de red
integrada y total, que incluya software, hardware, cableado,
mantenimiento, soporte, conectividad a Internet con acceso fijo y/o
móvil (WAP), actualización constante tanto de los programas como del
hardware y otros servicios igualmente interesante. Básicamente, se
trata de servir en alquiler software especialmente caro, personal
cualificado, servidores y canales de acceso de gran capacidad, de
manera que la empresa que contrata al PSA se evite esas inversiones
iniciales, que de entrada pueden resultar prohibitivas. La idea
consiste pues en alquilar en vez de comprar, externalizar en vez de
afrontar grandes gastos.

Las ventajas son evidentes. Aplicaciones o servidores que hasta ahora
sólo estaban al alcance de grandes empresas con recursos ilimitados
pasan a estar disponibles para cualquier pequeña o mediana empresa,
derribando así la barrera de entrada en nichos de mercado antes
cerrados. Adquirir una aplicación de Planificación de Recursos
Empresariales (ERP) o de Gestión de Relación con Clientes (CRM), un
lujo al alcance de unos pocos, con PSA se haría realidad para todos.
Desplegar una sofisticada aplicación de comercio electrónico, con la
consiguiente inversión en programas y servidores, mano de obra,
mantenimiento, etc., pasaría a ser una posibilidad asequible con PSA,
al alcance de pequeños empresarios de limitados recursos de TI. La
PSA hace frente a las necesidades de adquirir servidores más potentes
o canales de comunicación de mayor capacidad.

PSA se erige así en una herramienta de democratización, eliminando
muchas de las barreras económicas o tecnológicas de adquisición,
operación y mantenimiento de aplicaciones o recursos reservados
tradicionalmente a los grandes. Si tiene en su empresa un navegador y
conexión a Internet, ya puede operar una gran aplicación albergada en
un PSA. Pero no todo pueden ser ventajas, ¿cuál es su lado oscuro?
Por supuesto, su riesgo más evidente es para la seguridad de la
empresa que contrata al Proveedor de Servicios de Aplicaciones.
Cuanto mayor sea el atractivo de hacerse con la información mantenida
por el PSA, mayor será el número de ataques. Resulta obvio que de
forma natural los PSA se convertirán en blanco preferido de los
hackers.

Los servicios de seguridad mínimos exigibles al PSA serán:

- Cifrado de las comunicaciones, utilizando canales seguros con SSL
de 128 bits o acudiendo a tecnologías de VPN (cuidado aquí con
soluciones cerradas como PPTP de Microsoft, con agujeros ya
encontrados).
- Autenticación fuerte, basada en técnicas criptográficas robustas e
infalsificables, que por supuesto deberán guardar proporción con el
nivel de sensibilidad de la información a proteger.
- Detección de intrusos, escaneos de puertos y de otras operaciones
sospechosas. Se deberá dotar al sistema de una capacidad de respuesta
rápida y eficaz.
- Utilización de un sistema operativo seguro, o al menos, seguramente
configurado, con definición de permisos de accesos muy restrictivos y
especial cuidado en programas ejecutables accesibles a través de las
redes. Resulta fundamental que los clientes de un PSA no puedan
acceder a los datos de otros clientes (de la competencia) albergados
en el mismo PSA.
- Mantenimiento realizado preferiblemente desde las propias consolas
de los servidores, ya que se previenen problemas de agujeros en los
accesos remotos. Es importante establecer quién accede a los datos de
quién. ¿Puede un administrador del PSA acceder rutinariamente a la
información confidencial y sensible de una empresa?

A pesar de todas las medidas de seguridad, los mayores peligros a los
que se enfrenta un servicio de PSA ofrecido a través de redes
públicas son:

- Denegación de servicio: si el PSA deja de prestar el servicio
transitoriamente, bien por ataques de hackers, bien por causas
técnicas, la empresa puede ver su negocio seriamente afectado,
dependiendo su impacto de la mayor o menor necesidad de prestación
continuada del servicio a sus clientes. Hoy por hoy, habida cuenta
del ciclo de vida tradicional del software, donde son los clientes, y
no sus creadores, los que prueban el software y descubren
vulnerabilidades, resulta muy arriesgado confiar en que el PSA se
mantendrá a prueba de ataques con todas las brechas de seguridad
cerradas y que garantizará un servicio durante el 100% del tiempo,
incluso bajo ataques con éxito. La redundancia física y lógica de
servidores juega aquí un papel crítico.
- La línea Maginot: una vez más, el mayor riesgo no procede de fuera,
sino de dentro del propio PSA. Si alberga en él información
confidencial de gran valor, un empleado desleal del PSA o implantado
allí por un rival podría sentirse tentado de robarla para su uso o
venderla al mejor postor. Nadie como él conoce cómo funciona
internamente el Proveedor, por lo que nadie mejor que él para atacar
sin dejar rastro. Estos empleados también podrían ser vulnerables a
ataques de ingeniería social, sobornos, extorsiones, etc.

En la actualidad, los PSA se encuentran en su infancia. A pesar de la
publicidad, los riesgos superan con mucho a las ventajas como para
apostar fuerte por un PSA de acceso a través de redes públicas. Por
supuesto, esta situación cambiará en el futuro, especialmente en la
medida en que la seguridad se afronte como un objetivo prioritario
del ASP y no como una mera cláusula del contrato. Si está barajando
la idea de externalizar sus servicios, sopese bien las amenazas y
después, dude. La responsabilidad de la elección es muy grande. Al
fin y al cabo, está jugando con la seguridad de su empresa y de sus
clientes.

Más Información:
El fenómeno ASP:
http://www.idg.es/comunicaciones/mainart.asp?artid=106855

'Netsourcing': la revolución que viene:
http://www.nueva-economia.com/2000/NE028/NE028-38a.html




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



lunes, 24 de abril de 2000

Planes Nacionales para la Protección de Sistemas de Información

Debido al creciente interés de la sociedad norteamericana por la
protección de sus datos, y la preocupación por los cada vez más
numerosos "ataques electrónicos", la administración Clinton ha
elaborado el plan antes mencionada, en realidad son unas directrices
a seguir, que tarde o temprano se irán implantando no sólo en Estados
Unidos, si no también, querámoslo o no, en casi todo el planeta.
Con motivo de la elaboración del Plan Nacional para la Protección de
los Sistemas de Información (USA), se han celebrado recientemente unas
intervenciones a través del método de paneles on.line patrocinadas por
ZDNet (San Francisco).

El Plan Nacional tiene los siguientes diez puntos principales, o
recomendaciones generales, directrices de trabajo para mejorar los
sistemas de seguridad:

1)Identificar y solucionar las vulnerabilidades de los sistemas.
2)Detectar posibles amenazas.
3)Intercambio de información entre los cuerpos de inteligencia y
policía.
4)Compartir los avisos de ataque y la información con las empresas.
5)Construcción de sistemas que respondan al ataque y puedan recuperar
datos.
6)Investigación y desarrollo en seguridad.
7)Preparación de profesionales especialistas en seguridad, aunque
utiliza el término más amplio de "infosec".
8)Promocionar la seguridad a todos los niveles.
9)Adopción de legislación apropiada que beneficie este programa
nacional.
10)Asegurar la protección de las libertades civiles.

Una de las primeras conclusiones obtenidas sobre el plan, es que el
mismo no contiene ninguna recomendación o protección para el usuario
"de a pie", y así ante una pregunta de un ciudadano sobre "si el
gobierno (americano) tenía alguna guía o marco de trabajo para
asegurar la privacidad del usuario doméstico de ataques posibles", el
mismísimo Jeffrey Hunker, consejero de la Casa Blanca para estos
asuntos, dijo simple y sinceramente "La respuesta más corta es No",
"no hay aceptado una línea de trabajo sobre el particular, mientras
las corporaciones o empresas tienen práctica sobre el asunto, para
las personas apenas hay recomendaciones de este tipo".

Para Gregor Freund, presidente de Zone Labs, participante también en
el debate, la "seguridad es una responsabilidad personal, de la misma
manera que uno cierra el coche para que no le roben debería de
concienciarse de estos temas. Con los ataques DoS la gente se ha dado
cuenta que sus PCs son muy poderosos". Brad Templeton, (Fronteras
Electrónicas), manifestó que "la seguridad es algo que nos compete y
beneficia a todos", señalando que la Criptografía era tecnología
pro-privacidad y pro-derechos civiles. A lo que veladamente respondió
Kenneth C. Watson, (Cisco Systems) argumentado que "de la misma manera
que nadie se lamenta de perder un poco de su privacidad al atravesar
los detectores de metales en los aeropuertos para tener un vuelo
seguro", nadie debería tener ese reparo al entrar en Internet.

Sobre estos "ataques electrónicos", Stephanie Daman, profesional
británica especializada en seguridad, se preguntaba, en otro foro, si
los sistemas legales están preparados para esta nueva realidad. La
respuesta que ella misma daba era simplemente "No". No se ha creado
ningún marco global y acordado por todos que solucione este tipo de
problemas, ni siquiera con la intervención de la ONU ni de la OTAN.
Argumentando que "traspasar el problema a los organismos
internacionales no era más que eludir la propia responsabilidad de
los gobiernos, ya que la seguridad, los sistemas informáticos y las
redes se han convertido en algo vital para nuestro sistema de vida".

La solución dada en el Reino Unido, ha sido similar a la planteada
por Estados Unidos, así es, la creación de Centro para la
Coordinación Nacional de Infraestructuras de Seguridad (NISCC), para
coordinar actividades y ayuda contra los ataques electrónicos de
sistemas de vital importancia para el Reino Unido, intercambio de
información, toma de medidas para concienciar a la población y
empresas, preparación de profesionales y un largo etc., muy parecido
al Plan Norteamericano, aunque en este plan nacional se refuerza aun
más la idea de seguridad para el comercio, como instrumento de
desarrollo para las sociedades.

La idea de Stephanie Daman es contundente: el ahora es lo que
importa, no podemos conseguir seguridad por las vías del acuerdo
internacional, debemos hacerlo de forma nacional.

El problema es que si a nivel nacional tampoco se hace nada quedará
en manos de los ciudadanos y empresas realizar esta labor. Otro
problema que se apunta a simple vista, sobre la argumentación de
Stephanie Daman, es el de la armonización de legislaciones.

El Plan Nacional Norteamericano, sigue su curso y deberá evolucionar,
pero lo que es evidente es que marcará, o ya marca, la pauta a seguir
por casi todos los demás países, ahora mismo se presenta como Plan
Nacional "Versión 1.0 una invitación al dialogo".

Más información:

Plan Nacional para la Protección (USA) - formato PDF
http://www.zdnet.com/graphics/specialreports/national_plan.pdf

Lines of Defense. Poll: How worried are you?
http://www.zdnet.com/special/stories/defense/0,10459,2487277,00.html

Lines of Defense. Opinion: We don't need a cyber-NATO
http://www.zdnet.com/special/stories/defense/0,10459,2500202,00.html

Lines of Defense. No plan for personal cybersecurity
http://www.zdnet.com/special/stories/defense/0,10459,2553485,00.html




Eusebio del Valle
evalle@hispasec.com



domingo, 23 de abril de 2000

CriptoRed: Red Iberoamericana de Criptografía

CriptoRed se presenta como uno de los proyectos más ambiciosos dentro
del campo de la difusión criptográfica a través de Internet. Esta
red de cooperación docente con todos los países de Iberoamérica cuenta
ya, en sólo 3 meses, con más de 100 miembros, la mayoría de ellos
profesores de reconocido prestigio académico e investigador, así como
buen número de universidades y centros de investigación. Os invitamos
a conocer un poco más de este sitio web de la mano del Dr. Jorge Ramió
Aguirre, profesor de la Universidad Politécnica de Madrid, padre y
coordinador de CriptoRed.
*Pregunta:
¿Qué es una red temática y qué es específicamente CriptoRed?

Respuesta:
Las redes temáticas, en concordancia con la definición que de ellas
puede desprenderse de los Proyectos de Cooperación Docente que cada
año presenta a concurso la Agencia Española de Cooperación
Iberoamericana AECI, la forman 3 universidades españolas y 3
universidades de los países iberoamericanos que, con el visto bueno
de sus Rectores o autoridades máximas, presentan y coordinan sendos
cursos de formación que los profesores de España imparten en
Iberoamérica y otro tanto hacen los profesores de aquellos países en
España. Aunque el número de universidades participantes que aparece
en esas convocatorias es de tres, ello debe interpretarse no
obstante que, al menos, deberán participar esa cantidad de
instituciones por cada parte. Las ayudas económicas consisten
únicamente en los gastos de billetes de avión, quedando la
manutención y alojamiento a cargo de la universidad que recibe a los
profesores.

Criptored es algo más que una Red Temática. Tiene como objetivo
básico convertirse en un sitio virtual en Internet donde profesores,
investigadores y profesionales del sector de la seguridad informática
y la criptografía puedan aportar y compartir información, en especial
de carácter docente. Es más, la información sobre estos temas que allí
se almacene será, en su gran mayoría, de libre distribución (temarios
de asignaturas, planes de estudio, apuntes y notas de clase, exámenes,
software de prácticas, etc.) por lo que, además, los mayores
beneficiarios de esta supresión de fronteras de conocimientos en
seguridad serán varios miles alumnos. Téngase en cuenta que, tras el
Informe sobre la Enseñanza de la Criptografía en las Universidades
Españolas, publicado en el número 34 del mes de abril en la revista
SIC, sabemos que existen más de 1.600 estudiantes universitarios,
solamente en nuestro país, cursando este tipo de asignaturas en cada
curso académico y cabe esperar muchos más en los países de
Iberoamérica.

En este contexto, las universidades y centros de investigación que lo
deseen podrán contactarse de una forma más sencilla a través de
CriptoRed, de forma totalmente transparente, sin que ello signifique
de forma alguna que CriptoRed vaya a tener participación alguna en los
proyectos que se generen, entre ellos los propios de las redes
temáticas antes comentadas.

*Pregunta:
En la página de CriptoRed aparecen dos tipos de alta, la de tipo
personal limitada a profesores universitarios, investigadores y
profesionales y la denominada institucional, reservada sólo a
Universidades y Centros de Investigación. ¿Cómo se interpreta esto?

Respuesta:
Una red temática, por lo comentado anteriormente es, básicamente, un
proyecto de cooperación docente interuniversitario. La información que
se va a depositar en Criptored es, por tanto, en su mayor parte de
índole académico o docente. Dentro de estos temas está, cómo no,
resúmenes de proyectos de investigación desarrollados en las
universidades. Ahora bien, los Centros de Investigación son, en ese
aspecto, un referente muy importante y por ello se incluye a sus
investigadores en ese mismo grupo, aunque no impartan docencia
reglada. Por último, si en las empresas y organismos oficiales del
sector de la seguridad informática, la seguridad en redes y la
criptografía en general, un número considerable en España hay que
decirlo, nos encontramos con un importante número de técnicos
especializados en estos temas y son, además, las primeras que reciben
a nuestros titulados, ¿por qué dejarlas de lado? Aunque en este caso
no aportarán información docente a la red como los otros miembros,
sí se ha creído conveniente que estén dentro de la red y puedan
aportar información diversa; es más, su presencia puede ser de mucha
utilidad para futuros proyectos de colaboración.

Por otra parte, está lo que se ha denominado el Alta Institucional,
reservada sólo para Universidades y Centros de Investigación por dos
razones. Primero, por ser consecuente con el objetivo principal de
esta red, el intercambio de información docente y el hecho de estar
CriptoRed enmarcado en las denominadas Redes Temáticas, algo en
principio ajeno a las empresas y, segundo, debido a que la movilidad
de sus miembros es mucho menos significativa que en estas últimas.
Este tipo de alta va asociada con la designación por las autoridades
de esa institución de un Coordinador Local que tendrá como una de sus
funciones, además de la representatividad ante una asamblea de
miembros, la de hacer llegar al Coordinador General de la red
cualquier modificación de los datos correspondientes a esa institución
o noticia docente que se produzca y que pueda ser de interés para los
miembros de la red.

*Pregunta:
Ha hablado de fases en este proyecto. ¿Cuáles son y qué significan?

Respuesta:
En primer lugar, lo más importante era obtener un reconocimiento y
apoyo de la autoridad máxima de la Universidad Politécnica de Madrid,
su Rector. Como este proyecto tendría como objetivo los países
iberoamericanos, se proyectó realizar el documento de creación de
la red en una universidad chilena, en particular la Universidad de
Tarapacá en la ciudad de Arica. Al ser, junto con Argentina, los
países más lejanos del extremo sur, qué duda cabe que ese solo hecho
tenía un valor añadido. Aprovechando entonces una invitación del
Rector de dicha universidad para impartir un curso y dar algunas
conferencias sobre criptografía, y contando con el apoyo de la
Dirección de Relaciones con Latinoamérica de la UPM, en julio de
1999 durante mi visita se redacta en esa ciudad chilena el documento
de gestación de la red con el nombre "Programa de Fortalecimiento de
Grupos Docentes en la Enseñanza de la Seguridad Informática y
Protección de la Información". En él se detallan las acciones a
seguir en un período de tres años como ya se ha comentado.

Cumplida esa fase en el mes de octubre de 1999, que podríamos
denominar fase 0, una vez se reciben las cartas de apoyo
institucional de los respectivos Rectores, comienza en el mes de
diciembre de 1999 la Fase 1, que coincide con el nacimiento del
sitio Web, todavía bajo el servidor del departamento de LPSI. En
ella el objetivo principal es captar el mayor número de miembros
entre profesores e investigadores españoles de reconocido prestigio
en criptografía. Evidentemente, esta fase puede ser muy crítica si
la respuesta no es la esperada. No obstante, en menos de un mes se
supera la cantidad de 50 miembros y en estos momentos, tres meses
después, esta cantidad supera los 100. Todos ellos profesionales
de mucha valía y nivel académico, lo que da la seriedad al proyecto
que se estaba buscando desde el principio. Esta fase llega a su
práctica culminación a finales del mes de febrero del año 2000.

La segunda fase consiste en la promoción de esta red dentro de las
empresas del sector en España. Comienza a mediados del mes de
febrero de 2000. Como decía antes, éstas deben estar presentes en
la red aunque su aportación consista, tal vez en la mayoría de los
casos, solamente en compartir una información común. En este
apartado hay que considerar, además, el tema de los patrocinadores.
Estamos hablando de cualquier empresa, mediana o grande, que desee
contribuir a la buena marcha de esta iniciativa y que permita,
entre otras cosas, dar a conocer la red en los países de
Iberoamérica, en su momento contratar a algún becario que colabore
en funciones de actualización de datos, mantenimiento del sitio
Web, consultas a los Coordinadores Locales, etc. Y algo muy
importante: su colaboración económica permitirá afrontar los gastos
de adquisición de máquinas para el servidor, software específico para
su gestión y aquellos gastos de representación que no pueden cargarse
a los presupuestos ordinarios de las redes temáticas.

La fase 3, cuyo inicio se ha establecido a mediados del mes de marzo,
consiste en la solicitud formal a los miembros para el envío de
contenidos docentes al Coordinador General de la red, para ir
llenando de información el sitio Web, en especial en las secciones
Docencia e Investigación, en ese mismo orden de prioridad. Se espera
que para finales del mes de marzo o comienzos de abril, la mayoría
de las universidades españolas estén dadas de alta como institución
y que, por lo tanto, cuenten con un Coordinador Local para planificar
el envío o comprobación de estos datos con su centro.

Por último, la cuarta fase cuyo comienzo está planificado para
mediados del mes de abril, consistirá en el envío de documentación
sobre esta red y sus objetivos a la toda comunidad científica de
Iberoamérica. Este apartado de contacto con universidades de
Latinoamérica también se realiza en estos momentos, si bien de forma
muy esporádica y no como una campaña en el estricto sentido de la
palabra. Estamos hablando de más de 600 instituciones entre
universidades, centros de estudios superiores y de investigación de
las que, con toda seguridad, un buen número de ellas impartirán
docencia en carreras afines a estos temas, es decir por lo general
Ingenierías en Informática, Telecomunicaciones, Electrónica,
Industriales y Licenciaturas en Matemática.

Se espera que esta última fase, en donde se incluye tanto la
promoción de la red, la recepción y gestión de altas personales y
de instituciones como la de datos o contenidos, esté prácticamente
concluida en el verano europeo del año 2000. De esta forma, para
el inicio del curso académico 2000/2001, CriptoRed debería estar
ya completamente configurada y dando ese servicio a varios miles
de alumnos universitarios, profesionales y usuarios de la red en
general como predican sus objetivos.

Más información:
CriptoRed
CriptoRed nace para compartir información de criptografía



Bernardo Quintero
bernardo@hispasec.com



sábado, 22 de abril de 2000

Netscape permite leer ficheros locales desde servidores web

Netscape Communicator 4.x permite leer desde un servidor web ficheros
HTML del cliente, incluyendo el bookmark y la caché del navegador.
El ataque es posible siempre y cuando se conozca el nombre del perfil
del usuario y el navegador esté configurado para permitir interpretar
JavaScript y aceptar cookies, funcionalidades en las que se basa la
vulnerabilidad.
El problema surge porque Netscape permite incluir código JavaScript
en las cookies. Aprovechando esta particularidad, es posible diseñar
una cookie con código JavaScript que lea información del sistema
del usuario, apuntando por ejemplo a:

C:\Program Files\Netscape\Users\default\bookmark.htm

En esta ocasión suponemos que el nombre del perfil es "default", que
suele coincidir en muchas ocasiones por tratarse del nombre por
defecto. En el caso de que el usuario víctima utilice otro nombre de
perfil es tarea del atacante intentar averiguarlo.

Siguiendo con el ejemplo, la página web atacante llamaría en uno de
sus frames a la cookie que contiene el código JavaScript -que
anteriormente habría sido descargada por el usuario- a través de la
línea:

C:\Program Files\Netscape\Users\default\cookies.txt?/.html

Esta línea provocaría la ejecución del código JavaScript y la lectura
del bookmark sin ningún problema, ya que ambos ficheros, cookie y
bookmark, se encuentran en el disco duro local y por tanto en la misma
zona de seguridad para Netscape Communicator. Posteriormente los datos
obtenidos serían transmitidos al servidor web como parámetros en una
URL.

El descubridor de esta vulnerabilidad, Bennett Haselton, facilita una
demostración en línea:
http://peacefire.org/security/jscookies/jscookieset.html

A la espera de que Netscape solucione el problema, los usuarios
pueden deshabilitar las cookies o la ejecución de JavaScript en
Communicator, así como procurar que el nombre de perfil no sea
"default".




Bernardo Quintero
bernardo@hispasec.com



viernes, 21 de abril de 2000

Ataque DoS a Windows NT y 2000

Un argumento excesivamente largo en CMD.EXE, el intérprete de comandos
de Windows NT y 2000, provoca un desbordamiento de búfer que a su vez
puede derivar en la denegación de servicio del sistema al consumir
toda la memoria.
Tras provocar el desbordamiento de búfer el sistema muestra un cuadro
de diálogo con el mensaje de error, cuando esta ventana es cerrada el
sistema libera la memoria ocupada por el proceso. El problema surge en
los sistemas donde por cualquier causa, como por ejemplo ausencia del
administrador en la sesión, esta ventana no es cerrada, por lo que un
continuo ataque utilizando esta técnica acabaría por acaparar toda la
memoria del sistema.

Esta vulnerabilidad puede ser explotada remotamente en aquellos
servidores que utilicen el intérprete de comandos junto con
parámetros obtenidos desde el cliente. Esta situación es común
en muchos servidores webs que ejecutan ficheros de procesos por
lotes como scripts CGIs cuyos parametros pueden ser introducidos
fácilmente, por ejemplo, a través de la URL del navegador.

Microsoft ha facilitado los parches correspondientes de forma que
CMD.EXE compruebe la longitud de los parametros que se le pasan e
impida argumentos excesivamente largos que provoquen el
desbordamiento de búfer.

Parche:
Windows NT 4.0
Windows 2000

Más información:

Patch Available for "Malformed Environment Variable" Vulnerability



Bernardo Quintero
bernardo@hispasec.com



jueves, 20 de abril de 2000

FrontPage: eliminar DVWSSR.DLL, IMAGEMAP.EXE y HTIMAGE.EXE

Descubiertas vulnerabilidades por desbordamiento de búfer en
DVWSSR.DLL, IMAGEMAP y HTIMAGE.EXE, componentes de las Extensiones
de FrontPage y otras distribuciones, que pueden ser explotados
para ejecutar código arbitrario de forma remota en servidores web.
FrontPage es una herramienta de Microsoft para desarrolladores Web que
facilita y simplifica la creación y mantenimiento de las publicaciónes
en Internet gracias, entre otras, a las utilidades de administración
remota.

Para poder llevar a cabo la comunicación, entre el ordenador del
desarrollador y el sitio Web, es necesario que el servidor incorpore
los componentes necesarios, las Extensiones de FrontPage. Además de
incorporar los elementos para la comunicación entre servidor y
cliente, las Extensiones de FrontPage incorporan otros componentes
para dotar de mayor funcionalidad a las páginas web, como puede ser,
por ejemplo, un CGI para contar visitas.
DVWSSR.DLL, la supuesta puerta trasera de Microsoft

DVWSSR.DLL es uno de los componentes de FrontPage que se instalan en
los servidores web, su función consiste en permitir la comunicación
con los sistemas clientes de los desarrolladores para soportar la
característica "Link View", que permite visualizar de forma gráfica un
mapa del sitio web con la relación existente entre sus páginas.

Esta librería ha sido protagonista estas últimas semanas debido a un
informe de un consultor de seguridad, apodado "Rain Forest Puppy",
donde aseguraba haber descubierto una puerta trasera en DVWSSR.DLL a
través de la cual era posible para un desarrollador acceder al código
de las páginas .ASP o .ASA de otros dominios, distintos al suyo, que
se hospedaran en el mismo servidor.

En el informe quedaba descubierto el método de ofuscación utilizado
entre las librerías DVWSSR.DLL y MTD2LV.DLL, componentes servidor y
cliente de "Link View", para mantener sus comunicaciones ocultas. Como
elemento curioso, que ayudó a que la noticia saltara a los principales
medios de comunicación, se demostraba que la cadena utilizada en el
algoritmo de ofuscación era "Netscape engineers are weenies!",
traducido como "¡Los ingenieros de Netscape son unos canijos!".

Más tarde se demostraría que tal puerta trasera no existía, y que el
análisis de "Rain Forest Puppy" era incorrecto en parte. Todo indica
que en las pruebas realizadas los permisos estaban mal establecidos,
motivo por el cual se podía acceder a las páginas ASP fuera del ámbito
del usuario, y no por conocer el algoritmo de ofuscación, cuya única
funcionalidad es la de ocultar en la transmisión los nombres de los
ficheros que MTD2LV.DLL solicita a DVWSSR.DLL.

Con el exploit que acompañaba el análisis, en un sistema bien
configurado, se demostró que no era factible saltarse ningún control
de acceso, hecho que Hispasec adelantaba en primicia el viernes 14 de
abril en declaraciones al periódico El Mundo:

http://www.elmundo.es/navegante/diario/2000/04/15/ms_frontpage.html

Al mismo tiempo que la propia Microsoft desmentía la existencia de una
puerta trasera se confirmaba el hallazgo de una vulnerabilidad en la
misma librería por desbordamiento de búfer, que podía ser explotada
para ejecutar código arbitrario. Cuando todos esperaban el típico
parche para corregir la vulnerabilidad, Microsoft reconoce y confirma
el problema, pero ofrece como solución la eliminación de la librería
DVWSSR.DLL.
Microsoft pide también eliminar IMAGEMAP.EXE y HTIMAGE.EXE

También se han confirmado la posibilidad de provocar desbordamientos
de búfer en IMAGEMAP.EXE y HTIMAGE.EXE, dos componentes que Microsoft
incluye para soportar desde el servidor la funcionalidad de "image
mapping", enlaces por áreas gráficas, compatible con CERN
(HTIMAGE.EXE) y NCSA (IMAGEMAP.EXE).

Al igual que ocurriera con DVWSSR.DLL, Microsoft nos sorprende con
su "procedimiento" para estar libres de la vulnerabilidad, que no es
otro que buscar los ficheros afectados en todo el sistema y
eliminarlos.
Las distribuciones que instalan las ficheros descritos son:

- Extensiones FrontPage 97
- Extensiones FrontPage 98
- Option Pack para IIS y Windows NT 4.0
- Personal Web Server 4.0, para Windows 95 y 98
- Visual InterDev

En todos los casos Microsoft asegura que la eliminación de los
ficheros afectados no reporta perdida adicional de funcionalidad más
allá del propio cometido de los componentes. Es decir, al eliminar
éstos ficheros se perderá la característica "Link View" de FrontPage
e "image mapping" compatible con CERN y NCSA.
Más información:

A back door in Microsoft FrontPage extensions
http://www.wiretrip.net/rfp/p/doc.asp?id=45&iface=2

Microsoft secret file could allow access to Web sites
http://news.cnet.com/news/0-1003-200-1696137.html?tag=st.ne.1002.

MS IIS FrontPage 98 Extensions Filename Obfuscation Vulnerability
http://www.securityfocus.com/vdb/?id=1108

Un programa de Microsoft para servidores 'web'
supone un riesgo potencial para la seguridad de un sistema
http://www.elmundo.es/navegante/diario/2000/04/15/ms_frontpage.html

Microsoft security hole puts Web sites at risk
http://news.cnet.com/news/0-1003-200-1707928.html?tag=st.ne.1002.

Microsoft Security Bulletin (MS00-025)
http://www.microsoft.com/technet/security/bulletin/ms00-025.asp

Microsoft Security Bulletin (MS00-028)
http://www.microsoft.com/technet/security/bulletin/ms00-028.asp




Bernardo Quintero
bernardo@hispasec.com



miércoles, 19 de abril de 2000

El cifrado de pcAnywhere es inseguro

La última versión de pcAnyware 9.0 cifra los nombres de usuarios y
contraseñas de forma trivial, por lo que cualquier atacante con
acceso a las redes externas puede capturar esa información y
utilizarla para acceder a las máquinas remotas.
pcAnyware es un software para uso y administración remota de máquinas
MS Windows, por lo que este problema es especialmente importante, ya
que las máquinas remotas suelen encontrarse en redes hostiles.

Se desconoce si la versión 8.0 de pcAnyware es vulnerable también,
aunque se considera extremadamente probable. La versión 7.0 envía
los nombres de usuario y contraseñas directamente en texto claro,
a disposición de cualquier atacante con un sniffer.

El nombre de usuario y la contraseña están contenidas en una cadena
dos paquetes después de "Enter your login name" y "enter your
password". Están precedidas por el byte 0x06, y el siguiente número
es la longitud de la misma.

A continuación se incluye un programa en C que puede utilizarse para
descifrar una clave capturada con cualquier sniffer.



#include
#include

void main() {

char password[128];
char cleartext[128];
int i;

// input the sniffed hex values here
// Encrypted example of the 'aaaaa' password
password[0]=0xca;
password[1]=0xab;
password[2]=0xcb;
password[3]=0xa8;
password[4]=0xca;
password[5]='\0';

cleartext[0]=0xca-password[0]+0x61;
for (i=1;i cleartext[i] = password[i-1] ^ password[i] ^ i-1;

cleartext[strlen(password)]='\0';

printf("password is %s \n",cleartext);

}



Más información:

Symantec pcAnywhere Weak Encryption Vulnerability
http://www.securityfocus.com/vdb/bottom.html?vid=1093

Common Questions About Symmetric or Public Key Encryption in pcAnywhere
http://service1.symantec.com/SUPPORT/pca.nsf/docid/1999022312571812&src=w




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



martes, 18 de abril de 2000

El cifrado de Citrix ICA es inseguro

ICA (Independet Computing Architecture) es empleado en diversos
productos, como Winframe y Metaframe, que permiten el uso y
administración remota de máquinas tipo MS Windows. El cifrado ICA
básico es descifrable de forma trivial.
Ello implica que si estamos administrando una máquina de forma remota
utilizando alguno de estos productos, cualquiera con acceso a las redes
intermedias puede capturar la clave utilizada, y emplearla para tomar
control del sistema administrado.

Asimismo, las claves son almacenadas en el fichero de configuración del
servidor, "appsrv.ini", usando un cifrado también trivial. El paso
apropiado sería almacenar un "hash" de la clave, no la clave en sí. Al
menos en este caso un atacante tendría que recurrir a un ataque por
fuerza bruta.

Citrix comercializa también "SecureICA", empleando Diffie-Hellman y RC5.
Dado que el intercambio DH no está autentificado, es muy posible que el
sistema sea vulnerable a un ataque "man in the middle". Lamentablemente
"SecureICA" sólo está disponible para clientes Windows y DOS.

Este problema es importante desde el momento en que el principal uso de
ICA es, precisamente, la administración de máquinas Windows de forma
remota, típicamente en redes hostiles.

Más información:
ICA Weak Encryption Vulnerability
Decrypt stored Citrix ICA passwords (in appsrv.ini)
dsniff
Citrix SecureICA Service



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



lunes, 17 de abril de 2000

Documentación en castellano sobre criptografía

Nuestros lectores se encuentran que la mayor parte de la documentación
disponible sobre criptografía se edita únicamente en inglés, lo que
puede suponer un problema para algunos ellos. Afortunadamente existen
un buen número de iniciativas que intentan acercarnos la criptografía
en nuestro idioma. Una de las más destacables en este sentido es
Kriptópolis.
En el web de Kriptópolis van apareciendo poco a poco publicaciones en
castellano, aportadas por colaboradores desinteresados. En el momento
de escribir en el boletín, podemos encontrar:

Criptografía y Seguridad en Computadores
Manuel J. Lucena López

Introducción a los sistemas de curva elíptica
Gabriel A. Belingueres

Criptografía, Maple y RSA

Control de accesos
Manuel Pons Martorell

Hackers
Claudio Hernández

La caza del hacker (The Hacker Crackdown)
Original de Bruce Sterling, traducido al castellano por un equipo de
voluntarios

Criptología
Manuel Pons Martorell

Criptografía para principiantes
José de Jesús Ángel

Descripción de DES
Jorge Sánchez Arriazu

Apuntes de criptografía
Fernando Pardo Seco

Apuntes de Teoría de Códigos
Fernando Pardo Seco

La lista se va ampliando poco a poco, a medida que más y más
colaboradores ceden documentación para su uso libre y gratuito.

Además de este servicio bibliográfico, Kriptópolis edita un boletín
semanal, y también traduce al castellano el boletín periódico
"criptogram", del conocido Bruce Schneier (autor del más que
recomendable libro "Applied Cryptography" y de los criptosistemas
"blowfish" y "twofish").

Más información:
Kriptópolis
Kriptópolis: otras publicaciones
Kriptópolis: criptografía y seguridad en computadoras
Criptología



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



domingo, 16 de abril de 2000

SECURMATICA 2000

Securmática, el Congreso de Seguridad en Tecnologías de
Información y Comunicaciones que organiza la revista SIC
(Seguridad en Informática y Comunicaciones), va a celebrar
su undécima edición durante los días 25, 26 y 27 de abril
de 2000, en el Hotel Novotel, ubicado en el Campo de las
Naciones de Madrid.
En esta ocasión, se van a tratar asuntos relevantes en
estos tiempos de cambio, como por ejemplo las arquitectura
de comercio-e con garantías técnicas de prueba, los nuevos
horizontes normativos en materia de tratamiento de datos
personales, o los problemas de seguridad en los pagos
mediante telefonía celular. Al mismo tiempo, se va a
dedicar una sesión matutina a la exposición de cinco casos
de implantación en organizaciones de infraestructuras de
clave pública, PKI.

El Congreso se estructura en tres módulos que corresponden
a los días de celebración. El primer día, 25 de abril,
las ponencias se centran en su mayoría en la nueva Ley de
Protección de Datos. También tendrá lugar una mesa redonda
con bajo el título "¿Hacia dónde va la seguridad de la
información". A continuación, tendrá lugar una ponencia
sobre "Single Sign On Seguro, ¿panacea o quimera?", seguida
de otras dos centradas en la seguridad de los entornos
Windows de Microsoft, para terminar con una que trata
aspectos sobre el almacenamiento y la recuperación de la
información.

En el segundo módulo, a celebrar el día 26, el protagonismo
se centra en la seguridad del comercio electrónico, temática
que ocupará prácticamente la mitad de las ponencias. Otras
exposiciones trataran la seguridad de los ISPs en España,
vulnerabilidades en los servicios de voz sobre IP, las
últimas investigaciones del Grupo de Delitos de Alta
Tecnología de la Guardia Civil, y la tarjeta criptográfica
de la Fábrica Nacional de Moneda y Timbre-Real Casa de la
Moneda.

El día 27, tercera y última jornada, será la criptografía
el tema principal, junto con la banca por Internet y la
seguridad en redes IP.

Los precios para inscribirse en las jornadas oscilan entre
las 100.000 y 200.000 pesetas según los módulos escogidos,
con descuentos para las universidades y por número de
inscripciones de una misma empresa.

Más información:
SECURMATICA 2000
Programa (formato PDF)



Bernardo Quintero
bernardo@hispasec.com



sábado, 15 de abril de 2000

Vulnerabilidades y actualización de Panda Security

DeepZone hace público el resultado del análisis realizado sobre
Panda Security, el último producto de seguridad de la compañía
española Panda Software destinado a la protección de ordenadores
personales.
Panda Security implementa en los sistemas Windows 95/98
características de control de acceso, indentificación de
usuarios, y permite establecer permisos a los diferentes
recursos del sistema. Entre la funcinalidades podemos controlar
desde la utilización de dispositivos, hasta la navegación por
determinados sitios web, pasando por la posibilidad de cifrar
nuetros datos mediante Blowfish.

En el informe de DeepZone, anunciado en las principales listas
de seguridad, se describen algunas vulnerabilidades que permiten
desinstalar la aplicación y la escalada de privilegios hasta el
nivel de administrador. A continuación ofrecemos el anuncio de
DeepZone, donde facilita el acceso al informe detallado de las
vulnerabilidades y exploits, para finalizar con el comunicado
de Panda Software a HispaSec donde anuncia la solución de estos
problemas.

Anuncio de las vulnerabilidades
-------------------------------

OVERVIEW
Todas las builds de Panda Security 3.0 por debajo de la 3.0.2.0
presentan numerosas vulnerabilidades. Cualquier usuario con
cuenta en el sistema puede aprovecharlas para aumentar sus
privilegios en el mismo.

Cualquier usuario puede llegar a ser Administrador en un sistema
protegido por Panda Security 3.0

BACKGROUND
Ideas y exploits han sido probadas contra la version española de
Panda Security 3.0 (builds 3.0.0.71/96) siendo exitosas.

Tanto la version española como la internacional por debajo de
la build 3.0.2.0 son vulnerables.

DETAILS
Panda Security 3.0 es vulnerable a "merging" indirecto de llaves
en el registro. Un error en algunas releases previas a la 3.0.2.0
permite que cualquier atacante pueda deshabilitar llaves criticas
en el sistema pudiendo asi aumentar sus privilegios en el mismo o
incluso desinstalar y/o manipular el producto.

Otro bug relacionado con la instalacion/desinstalacion de
aplicaciones en el sistema permite que cualquier usuario pueda
desinstalar Panda Security 3.0.

Un analisis detallado, asi como los exploits y el rootkit que
acompañan a dicho analisis demuestran las vulnerabilidades del
producto.

Analisis detallado, exploits & rootkit pueden ser descargados
de http://deepzone.cjb.net

FIXES/PATCHES
Panda Software ha sido contactada hace dos semanas. Su respuesta
ha sido inmediata. Tanto los parches como una nueva version
arreglando las vulnerabilidades presentes en este documento
podran ser descargadas en breve de ...

http://www.pandasoftware.es (version española)
http://www.pandasoftware.com (version internacional)

La lista oficial de builds liberadas hasta el momento proporcionada
por Panda Software es la siguiente ...

3.0.0.77 Simo 99 => Vulnerable
3.0.0.90 Multimedia Ediciones => Vulnerable
3.0.0.96 Enero 2000 - primer upgrade importante => Vulnerable
3.0.0.97 => Vulnerable
3.0.0.100 => Vulnerable

La version que se espera solucione estos bugs es la _3.0.2.0_

Recomendado actualizarse.
Comunicado emitido por Panda Software
-------------------------------------

Panda Software informa que ya había detectado y corregido la
vulnerabilidad de las versiones 3.0.0.77, 3.0.0.90, 3.0.0.96,
3.0.0.97 y 3.0.0.100 de Panda Security antes de que DeepZone
informara públicamente de ella.

En la actualidad, la versión 3.0.2.0 -en la que se ha fortalecido
la seguridad-, se encuentra en fase de verificación y, en un
corto espacio de tiempo, estará disponible en el mercado. En ese
momento, y gracias a la capacidad de actualización de todo el
software de Panda, los usuarios de Security podrán actualizar,
vía web, su versión. Ésta también incluye importantes mejoras
que facilitarán al administrador la gestión de restricciones de
archivos y del registro.

Más información:
DeepZone
Panda Software



Bernardo Quintero
bernardo@hispasec.com



viernes, 14 de abril de 2000

Spidering

Las semanas próximas se van a ventilar algunas demandas en Estados
Unidos que podrían empezar a cambiar algunos conceptos actuales
sobre Internet, propiedad,o intrusión en sistemas. De ellas, tal vez,
destaca la que se plantea entre el gigante eBay y la web Bidder´s
Edge. En breve se discutirá, ante el Juez Ronald M. Whyte del Juzgado
Federal de Distrito de San José, (California-USA), la legalidad o no
de la técnica conocida como "spidering".
Bidder´s Edge es una web site, que entre otras cosas, facilita al
visitante la búsqueda de artículos o servicios que estén disponibles
en diferentes web-sites que se dedican a subastar objetos en línea,
entre ellas eBay. Podríamos decir que hace labor de intermediación.

Para reunir esa información, utiliza un robot, un "spider" (araña),
que de forma rutinaria peina determinadas web-sites y extrae
información de ellas, esa información, no protegida por el copyright,
se transfiere a la base de datos de Bidder´s Edge facilitando las
búsquedas al visitante de su web-site.

Por estos hechos, eBay demandó el año pasado a Bidder´s Edge
alegando que el "spidering" supone una intrusión en sus sistemas de
ordenadores, y les acusa, también, de lucro indebido. Bidder´s Edge
se defiende alegando prácticas monopolísticas. Tan de moda estos
días.

La visión que se tiene sobre Internet es totalmente diferente en
uno u otro bando.

Para los abogados de Bidder´s Edge, Internet es como una gran
biblioteca, llena de información que debe ser abierta y disponible
para todos los usuarios. Para ellos las listas de subastas de eBay
son información pública, no sujeta a obtención de permiso para su
utilización, ya que no está sometida dicha información a los
derechos de copyright.

Por otro lado, sostienen, que cuando se abre al público una
web-site, se abre a todo el mundo, incluido los robots, más cuando
estos no dañan los sistemas informáticos visitados, y sólo recogen
información sobre precios y objetos a la venta. Cosa muy libre en
un sistema capitalista, y que beneficia tanto al vendedor original,
(pues su oferta es vista por más gente), como al comprador al que
se le facilita la búsqueda del objeto que desea.

Al parecer ellos, siguen esa politica, se denominan asímismo como
"la primera compañía en ofrecer objetos y servicios de subasta
para su usuarios", y dentro de su web anuncian y utilizan dos
tipos de información: la personal dada de forma voluntaria, y la
dada de forma anónima y utilizada como un todo de la información
conjunta de su web. Es decir, parece que están abiertos, también
a ser objeto de spidering por terceras compañias o usuarios.

Para los abogados de eBay el planteamiento es diferente, no se
basan tanto en el derecho o no al copyright, sino al derecho de
limitar el acceso a propiedad privada, ya que los ordenadores a
los que se accede son propiedad de eBay, aunque la información
que contengan sea pública o realizada por sus clientes, los
cuales van dejando en su site datos para comprar y vender en
subastas.

Por lo visto, eBay intentó disuadir a Bidder´s Edge de diferentes
maneras, tanto legales (intentando negociar una licencia), como
técnicas mediante cortafuegos y sistemas de seguridad, sin
resultado alguno.

En Estados Unidos, el uso de spiders está bastante extendido,
(basta con marcar el termino en un buscador como Yahoo! para
darse cuenta de ello), aunque no lo reconoce todo el mundo.

Está será la primera sentencia que dictamine sobre esta práctica.
Deberá la sentencia determinar que clase de control pueden las
empresas mantener sobre información publica, y disponible en
sus sites. Y si el uso de estos robots o spiders se puede
considerar intrusión en sistemas y/o violación de propiedad
privada.

En esta semana se hará la primera vista, (se podría llegar a
un acuerdo comercial), caso de no haber acuerdo, se espera la
sentencia para antes del verano.




Eusebio del Valle
evalle@hispasec.com



jueves, 13 de abril de 2000

¿Vulnerabilidad en el código "IP Marquerade" de Linux 2.2.x?

El código "IP Masquerade" de las versiones kernel 2.2.x de Linux es
vulnerable a un ataque que permite que un atacante remoto pueda
introduzca datagramas UDP en una red local protegida con "IP
Masquerade". Pero, ¿qué significa eso exactamente?.
"IP Marquerade" es el nombre que se dá en Linux al sistema NAT (Network
Address Translation) nativo, y que permite que toda una red corporativa
acceda a Internet utilizando una única IP, por ejemplo. Este sistema,
además de posibilitar el empleo de una única IP (que ni siquiera
necesita ser fija), proporciona cierta protección del tipo
"cortafuegos", ya que las máquinas externas (Internet) no pueden
establecer conexiones con máquinas internas, a menos que sean éstas
quienes lleven la iniciativa.

El problema con el "IP Masquerade" y el protocolo UDP es que bajo
determinadas condiciones (relativamente simples), un atacante puede
introducir datagramas UDP en la red local en "respuesta" a datagramas
provenientes del interior, aunque él no sea el destinatario de los
mismos.

En realidad -y esto es importante- no se trata de un error en el código
"IP Masquerade", sino en un requisito de diseño necesario porque, en
mucho casos, un datagrama UDP es respondido utilizando una IP diferente
de la originaria (por ejemplo, servidores de nombres DNS o servidores
NFS).

Ante este problema hay dos soluciones sencillas:

* Filtrar los datagramas UDP salientes de la red, de forma que no usen
"IP Masquerading". Ello implica tener funcionando un servidor DNS
en la propia máquina que hace de encaminador.

* Forzar a que todas las respuestas UDP provengan de la IP
correcta. Este parche puede dar un falso sentido de seguridad,
porque el protocolo UDP no está orientado a conexión y las IPs
son fácilmente falsificables.

Para ello aplicamos el siguiente parche al Kernel:

--- net/ipv4/ip_masq.c.dloose Thu Mar 30 14:51:06 2000
+++ net/ipv4/ip_masq.c Thu Mar 30 14:57:24 2000
@@ -415,7 +415,7 @@
/*
* By default enable dest loose semantics
*/
-#define CONFIG_IP_MASQ_LOOSE_DEFAULT 1
+/* #define CONFIG_IP_MASQ_LOOSE_DEFAULT 1 */

/*

Más información:
Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities
FAQ: Firewalls: What am I seeing?



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



miércoles, 12 de abril de 2000

Ataque de denegación de servicio a pcANYWHERE

Las versiones 8.0 y 9.0 de Symantec pcANYWHERE son susceptibles de un
ataque de denegación de servicio (DoS).
pcANYWHERE es un programa de control remoto de máquinas con Windows
95/98/NT/2000, de forma tal que un usuario remoto pueda manejar el
ordenador como si estuviese sentado delante suya. En cierto modo es un
sistema similar al celebérrimo X-Window del mundo UNIX, o al reciente
VNC.

Un cliente malicioso puede matar el servidor PCAnywhere simplemente
intentando conectarse a él, y abortando la conexión mientras el programa
muestra en la barra de estado el texto "PCAnywhere connecting...".

Cuando la version 8.0 del servidor PCAnywhere muere, la única
posibilidad de recuperar el servicio (aparte de reiniciando la máquina,
por supuesto) es acceder a ella físicamente y relanzando el servicio:

net stop awhost32
net start awhost32

Si estamos trabajando con la versión 9.0, el servicio puede reanudarse
conectándonos con telnet al puerto 5631 de la máquina en cuestión.

PS: En un entorno de aplicación de este estilo, se suele denominar
"servidor" al programa que se ejecuta en la máquina en la que se
encuentra el usuario, ya que "sirve" las peticiones de visualización de
las aplicaciones remotas. En este boletín, no obstante, empleamos la
nomenclatura más usual, aunque estrictamente hablando sea incorrecta.

Más información:
PCAnywhere Denial of Service Vulnerability



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



martes, 11 de abril de 2000

Ataque DoS local sobre Linux

Las versiones anteriores a la 2.2.15pre16 del kernel Linux son
susceptibles a un ataque DoS (denegación de servicio) local.
El problema se produce cuando un usuario local intenta escribir un
datagrama de gran tamaño en un "unix socket" de la máquina. El kernel se
bloquea con un mensaje de error, y la única forma de recuperar el
control es reiniciando el ordenador.

Como es habitual con el software de código abierto, el problema fue
resuelto unas pocas horas después de haberse hecho público.

Los administradores deberían actualizar a la versión 2.2.15pre16 o
superior del kernel Linux. Las personas que no puedan descargar la
última versión del kernel, pueden aplicar el siguiente parche (para
2.2.x):



--- linux.vanilla/net/unix/af_unix.c Sat Aug 14 02:27:46 1999
+++ linux.15pre16/net/unix/af_unix.c Tue Mar 28 17:27:52 2000
@@ -969,6 +969,10 @@
return -ENOTCONN;
}

+ err = -EMSGSIZE;
+ if (len > sk->sndbuf)
+ goto out;
+
if (sock->passcred && !sk->protinfo.af_unix.addr)
unix_autobind(sock);



Más información:
Multiple Linux Vendor Domain Socket Denial of Service Vulnerability
Alan Cox upgrade linux-2.2.15pre16.tar.gz



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



lunes, 10 de abril de 2000

Advert.dll, la dll de la polémica (II)

Recientemente saltó a todos los medios el caso de Advert.dll, una dll
que se instalaba con un gran número de aplicaciones shareware de
renombre, y que según todas las informaciones estaba destinada a espiar
las transmisiones de los usuarios. Ofrecemos a todos nuestros lectores
la continuación del completo análisis que el Laboratorio de HispaSec ha
realizado sobre advert.dll.
Las comunicaciones

Otras de las acusaciones a las que ha sido sometido Aureate tienen que
ver con su supuesta capacidad para mantener comunicaciones en secreto
y enviar información sensible del usuario a través de Internet. En
primer lugar, las comunicaciones con los servidores de publicidad, a
través de TCP, pueden ser detectadas con un simple NETSTAT -A. En
cuanto al segundo punto, en las pruebas de monitorización de las
comunicaciones a nivel de paquete no he encontrado información
adicional fuera de la que se contempla en el propio acuerdo de
licencia con el usuario: ID del usuario, información del perfil
recogido por los formularios, versión del software, o los banners. El
único punto negro en este apartado pueden ser las cookies de los
servidores de publicidad, que en principio no se contemplan
explícitamente en la documentación.

En el texto que Aureate pide a los desarrolladores que integren en sus
propias licencias, y que como hemos visto anteriormente en la mayoría
de las ocasiones hacen caso omiso, se indica que los anuncios se
entregan vía Internet y serán descargados de los servidores de Aureate
Media o de sus subcontratistas, socios, u otras partes autorizadas.
Por último, informa que el software conectará con Internet para la
transferencia de actualizaciones del propio software y deja bajo la
responsabilidad del usuario cualquier coste del uso de la red u otro
derivado del programa.

Una vez se lanza cualquier programa que haga uso de la tecnología
Aureate se produce un intento de comunicación con los servidores según
la información que tiene almacenada en el registro de Windows. En
algún foro se ha barajado la posibilidad de modificar los parámetros
de los servidores en el registro para que apunten a otra dirección,
como puede ser la local, y así evitar las acciones de Aureate. Esta
acción no tiene ninguna repercusión en realidad, ya que la librería
advert.dll lleva consigo direcciones predeterminadas para modificar el
registro en caso de problemas.

Cada vez que una aplicación que lleve el sistema de Aureate intenta la
comunicación se provoca una media de 150 paquetes TCP y
aproximadamente 21.600 bytes -según condiciones-, a través de la cual
el cliente envía su ID al servidor lo que le permite identificar el
perfil del usuario, enviado la primera vez que se instala Aureate, y
cruzarlo con todos sus datos estadísticos. Aquí podemos ver uno de
esos paquetes capturados en las pruebas:


0000: C4 55 FB 00 01 01 00 01 B0 56 9A 80 08 00 45 00 .U.......V....E.
0010: 00 36 6F 08 40 00 80 06 F9 85 D4 3B D8 46 D8 25 .6o.@......;.F.%
0020: 0D 8C 04 86 07 B7 00 38 87 80 4B 49 D9 B7 50 18 .......8..KI..P.
0030: 22 19 A0 B9 00 00 00 00 00 00 06 77 6F 14 31 00 "..........wo.1.
0040: 00 00 FB 35 ...5

Del que podemos ver que se trata de un paquete TCP, donde la dirección
de destino es la 216.37.13.140, que equivale a "ad2-1.aureate.com",
dirigido al puerto 1975 (07B7) y entre los datos podemos encontrar la
cadena "00 00 00 00 06 77 6F 14" que concuerda con el ID que en la
prueba tenía almacenado en la clave

HKEY_CURRENT_USER\Software\Aureate\Advertising\Demographics
valor "User ID", dato "14 6f 77 06 00 00 00 00".

Entre la información que intercambian el servidor de Aureate y el
cliente se envía un paquete en el que se indica donde tiene que
recoger el próximo banner.

0000: 00 01 B0 56 9A 80 C4 55 FB 00 01 01 08 00 45 00 ...V...U......E.
0010: 00 C4 9C D4 40 00 75 06 D6 2B D8 25 0D 8C D4 3B ....@.u..+.%...;
0020: D8 46 07 B7 04 86 4B 49 D9 DE 00 38 87 DF 50 18 .F....KI...8..P.
0030: 21 CC 0F 42 00 00 80 00 00 00 44 68 74 74 70 3A !..B......Dhttp:
0040: 2F 2F 6B 61 6E 73 61 73 2E 76 61 6C 75 65 63 6C file://kansas.valuecl
0050: 69 63 6B 2E 63 6F 6D 2F 72 65 64 69 72 65 63 74 ick.com/redirect
0060: 3F 68 6F 73 74 3D 68 30 30 32 34 34 36 39 26 62 ?host=h0024469&b
0070: 3D 69 6E 64 65 78 70 61 67 65 26 76 3D 30 00 81 =indexpage&v=0..
0080: 00 00 00 3C 9F 00 00 00 48 68 74 74 70 3A 2F 2F ...<....Hhttp://
0090: 6B 61 6E 73 61 73 2E 76 61 6C 75 65 63 6C 69 63 kansas.valueclic
00A0: 6B 2E 63 6F 6D 2F 63 79 63 6C 65 3F 68 6F 73 74 k.com/cycle?host
00B0: 3D 68 30 30 32 34 34 36 39 26 62 3D 69 6E 64 65 =h0024469&b=inde
00C0: 78 70 61 67 65 26 6E 6F 73 63 72 69 70 74 3D 31 xpage&noscript=1
00D0: 00 02 ..

Entonces el cliente Aureate hace una petición HTTP a la dirección para
recibir el banner, donde además el nuevo servidor que entra en juego
aprovecha para enviar sus cookies que Aureate se encarga de manejar y
almacenar en el registro de Windows. Por lo tanto, además del
seguimiento que realiza Aureate a través de sus servidores, se produce
un segundo control por los servidores de publicidad de donde se
recogen los banners, aspecto éste que tampoco he podido encontrar
reflejado en el acuerdo de licencia con el usuario. En las pruebas
realizadas este segundo servidor ha redirigido una vez mas a nuestro
cliente a un tercer servidor que ha sido el encargado de suministrar
el banner en formato GIF. En la prueba de comunicación realizada, con
una duración de 10 minutos, el cliente de Aureate ha realizado 4
peticiones de nuevos banners siempre obteniendo resultados similares a
los comentados.

La librería amcis.dll, el "lado oscuro"

Todo el protagonismo de las informaciones arrojadas sobre el caso
Aureate ha recaido sobre la librería advert.dll, una de las fijas en
las primeras versiones de este software. De manera incomprensible se
ha olvidado a amcis.dll, otra de las librerías que tampoco podían
faltar en esas distribuciones, cuyo estudio despeja algunas incógnitas
y nos muestra un lado que hasta la fecha había permanecido oculto en
toda esta trama.

Durante el proceso de instalación la librería amcis.dll se identifica
como clase con un valor específico, de 128 bits, el denominado Class
ID en el registro de Windows bajo la clave CLSID. A través de la
aplicación regedit podemos realizar una busqueda de la cadena
"BDF0-11D2-BBE5-00609419F467" para encontrar todas las referencias de
las creaciones de objetos relacionados con esta librería. En algunas
podemos observar como en el valor InprocServer32 se apunta a la
librería en cuestión, por ejemplo "c:\windows\system\amcis.dll" junto
con el valor ThreadingModel con el dato "Apartment" que indica que el
objeto solo puede ejecutarse en un apartamento de un único hilo.
Además se crean otras entradas con los valores Stub.NetscapeStop.1,
Netscape Starting, Automation Shutdown, Automation Startup,
Stub.NetscapeStop, Stub.CIEStub.1, Stub.CIEStub y como Browser Helper
Objects.

El resultado de todo este entramado de registros es que cada vez que
se lanza una instancia de Internet Explorer o Netscape la librería
amcis.dll es cargada en memoria en el mismo proceso que el navegador.
En ese momento la librería se encuentra conectada con IExplorer, de
forma que puede tener el control del navegador así como "escuchar" los
eventos que en él sucedan mediante una interfaz. Además, amcis.dll
realiza una llamada a advert.dll, por lo que el resultado final es que
ambas librerías son lanzadas al abrir el navegador, sin necesidad de
que se encuentre en memoria la aplicación que hacía uso de la
tecnología Aureate, incluso habiéndola desinstalado. A continuación un
ejemplo de las librerías que se encuentran en memoria y enlazadas con
Internet Explorer en el sistema objeto de las pruebas de este
análisis, se pueden observar, entre otras, amcis.dll y advert.dll.

Base Size Version Path
0x00400000 0x13000 5.00.2314.1000 C:\Program Files\Plus!\Microsoft Internet\IEXPLORE.EXE
0x77f60000 0x5e000 4.00.1381.0174 C:\WINNT\System32\ntdll.dll
0x77dc0000 0x3f000 4.00.1381.0203 C:\WINNT\system32\ADVAPI32.dll
0x77f00000 0x5e000 4.00.1381.0178 C:\WINNT\system32\KERNEL32.dll
0x77e70000 0x54000 4.00.1381.0133 C:\WINNT\system32\USER32.dll
0x77ed0000 0x2c000 4.00.1381.0115 C:\WINNT\system32\GDI32.dll
0x77e10000 0x57000 4.00.1381.0193 C:\WINNT\system32\RPCRT4.dll
0x70bd0000 0x44000 5.00.2314.1000 C:\WINNT\system32\SHLWAPI.dll
0x70f20000 0xe6000 5.00.2314.1000 C:\WINNT\System32\shdocvw.dll
0x71590000 0x87000 5.80.2314.1000 C:\WINNT\system32\COMCTL32.dll
0x77c40000 0x13c000 4.00.1381.0171 C:\WINNT\system32\SHELL32.dll
0x71730000 0x57000 5.00.2314.1000 C:\WINNT\System32\shdoclc.dll
0x70400000 0x77000 5.00.2314.1000 C:\WINNT\System32\MLANG.DLL
0x77b20000 0xb6000 4.00.1381.0190 C:\WINNT\system32\ole32.dll
0x71020000 0xc4000 5.00.2314.1000 C:\WINNT\System32\BROWSEUI.dll
0x717a0000 0xb000 5.00.2314.1000 C:\WINNT\System32\browselc.dll
0x779b0000 0x9000 4.00.1371.0001 C:\WINNT\System32\LinkInfo.dll
0x77720000 0x11000 4.00.1381.0027 C:\WINNT\system32\MPR.dll
0x77a40000 0xd000 4.00.1381.0027 C:\WINNT\System32\ntshrui.dll
0x78000000 0x47000 6.01.8455.0000 C:\WINNT\system32\MSVCRT.dll
0x77800000 0x3a000 4.00.1381.0093 C:\WINNT\system32\NETAPI32.dll
0x77840000 0x9000 4.00.1371.0001 C:\WINNT\system32\NETRAP.dll
0x777e0000 0xd000 4.00.1381.0135 C:\WINNT\system32\SAMLIB.dll
0x10000000 0xc000 1.00.0000.0001 C:\WINNT\System32\amcis.dll
0x65340000 0x92000 2.40.4275.0001 C:\WINNT\system32\OLEAUT32.dll
0x01200000 0x8d000 1.05.0001.0018 C:\WINNT\System32\advert.dll
0x776d0000 0x8000 4.00.1381.0201 C:\WINNT\system32\WSOCK32.dll
0x776b0000 0x14000 4.00.1381.0172 C:\WINNT\system32\WS2_32.dll
0x776a0000 0x7000 4.00.1381.0031 C:\WINNT\system32\WS2HELP.dll
0x77d80000 0x32000 4.00.1381.0133 C:\WINNT\system32\COMDLG32.dll
0x70280000 0x6e000 5.00.2314.1003 C:\WINNT\System32\urlmon.dll
0x77a90000 0xb000 4.00.1371.0001 C:\WINNT\system32\VERSION.dll
0x779c0000 0x8000 4.00.1371.0001 C:\WINNT\system32\LZ32.dll
0x71190000 0x7000 5.00.2314.1000 C:\WINNT\system32\MSIDLE.DLL
0x77bf0000 0x7000 4.00.1381.0160 C:\WINNT\System32\rpcltc1.dll
0x70200000 0x70000 5.00.2314.1003 C:\WINNT\System32\WININET.DLL
0x717e0000 0x9000 5.00.2314.1000 C:\WINNT\System32\shfolder.dll
0x777f0000 0xc000 4.00.1381.0027 C:\WINNT\System32\ntlanman.dll
0x77890000 0x15000 4.00.1381.0046 C:\WINNT\System32\NETUI0.dll
0x77850000 0x3a000 4.00.1381.0046 C:\WINNT\System32\NETUI1.dll
0x017b0000 0x36000 4.01.0000.0000 C:\PROGRA~1\GetRight\XX2GR.DLL
0x77c00000 0x18000 4.00.1381.0027 C:\WINNT\System32\WINSPOOL.DRV
0x77660000 0xf000 4.00.1381.0037 C:\WINNT\system32\msafd.dll
0x77690000 0x9000 4.00.1381.0037 C:\WINNT\System32\wshtcpip.dll
0x75320000 0x22000 4.00.1381.0194 C:\WINNT\System32\RASAPI32.DLL
0x74a10000 0x1f000 4.00.1381.0135 C:\WINNT\System32\TAPI32.dll
0x750f0000 0x10000 4.00.1381.0194 C:\WINNT\System32\RASSCRPT.dll
0x75210000 0x7000 4.00.1371.0001 C:\WINNT\System32\RASFIL32.dll
0x752f0000 0xb000 4.00.1381.0194 C:\WINNT\System32\rascauth.dll
0x751a0000 0x12000 4.00.1381.0194 C:\WINNT\System32\rasman.dll
0x74ff0000 0xe000 4.00.1381.0201 C:\WINNT\System32\rnr20.dll
0x75360000 0x7000 4.00.1371.0001 C:\WINNT\System32\rasadhlp.dll
0x70c30000 0x240000 5.00.2314.1002 C:\WINNT\System32\mshtml.dll
0x4a000000 0x2c000 6.00.0000.8169 C:\WINNT\System32\PDM.DLL
0x4aa00000 0x15000 6.00.0000.8146 C:\WINNT\System32\MSDBG.DLL
0x76ab0000 0x5000 4.00.1381.0001 C:\WINNT\System32\IMM32.DLL
0x711b0000 0x76000 5.00.0000.3715 C:\WINNT\System32\jscript.dll
0x48080000 0x28000 3.10.0337.0000 C:\WINNT\System32\MSLS31.DLL

Esta particularidad daría argumentos a aquellos que quieren ver en
Aureate un troyano: el sistema enlaza con los navegadores para
asegurarse su ejecución sin necesidad de los programas anfitriones,
además con la posibilidad de espiar los eventos que suceden mientras
navegamos.

En las pruebas realizadas no se ha podido detectar en ningún caso que
las librerías cargadas en memoria por Internet Explorer, sin la
mediación de los progamas anfitriones, mantuvieran algún tipo de
comunicación con los servidores de publicidad. Por lo que respecta a
este análisis la única evidencia, demostrada, es que las librerías de
Aureate se cargan en memoria cuando se lanzan los navegadores de
Microsoft o Explorer, incluso tras la desinstalación de los programas
anfitriones con las que se distribuyeron dichas DLLs.

Las pruebas en este apartado han consistido en el análisis a nivel de
paquetes derivado de la navegación al azar durante 10 minutos. En el
debe queda realizar el análisis por un periodo de tiempo más
prolongado, así como comprobar si estas librerías utilizan su posición
en memoria para seguir actualizando las cookies registradas por los
servidores de publicidad.

Desinstalar Aureate

Por Internet ya circulan algunas utilidades que tienen como fin el
desinstalar el sistema de Aureate, en los casos probados ninguna de
ellas realiza la desinstalación total de las DLLs de las diferentes
versiones, y mucho menos de las entradas del registro. Además,
provocan que los programas que utilizan esta tecnología dejen de
funcionar. Con la información proporcionada en este análisis se puede
llevar a cabo la limpieza total o parcial, a base de borrar todas las
librerías y registros del sistema mencionados. En el caso de que se
quieran conservar los programas con tecnología Aureate en
funcionamiento, pero se desee eliminar la activación automática con
los navegadores, bastará con borrar la librería amcis.dll, así como
sería adecuado eliminar las entradas en el registro que le hacen
referencia.


Bernardo Quintero
bernardo@hispasec.com



domingo, 9 de abril de 2000

Advert.dll, la dll de la polémica (I)

Recientemente saltó a todos los medios el caso de Advert.dll, una dll
que se instalaba con un gran número de aplicaciones shareware de
renombre, y que según todas las informaciones estaba destinada a espiar
las transmisiones de los usuarios.
El sistema AdSoftware de Aurete Media Corporation se basa en ofrecer a
desarrolladores la posibilidad de incluir en sus aplicaciones
publicidad, a modo de banners, con la consiguiente retribución
monetaria según el volumen de publicidad que son capaces de
soportar -usuarios/tiempo que utilicen la aplicación-. En estos
momentos se cuentan por cientos las aplicaciones que utilizan esta
tecnología (listado en:
http://www.aureate.com/advertisers/network_members.html), con títulos
tan conocidos y extendidos como GetRight o CuteFTP, y que tienen en
común la utilización de Internet para llevar a cabo sus funciones, ya
que de lo contrario el sistema no podría actualizar los banners y
realizar el seguimiento.

El rumor parte, como suele ser habitual, en los foros de Internet
(primeras informaciones en:
http://news.cnet.com/news/0-1005-200-1558696.html) y provoca enseguida
un efecto bola de nieve entre informadores y usuarios que terminan por
sembrar, como mínimo, la duda en la comunidad de usuarios. Una de las
fuentes más activas en este caso en la que se han basado muchas de las
informaciones arrojadas son los comentarios de Steve Gibson en su
sitio web (http://grc.com/optout.htm).

Avisos y Acuerdo de Licencia

Entre los requerimentos, para que terceros puedan aplicar la
tecnología AdSoftware en sus programas, Aureate pide que se incluya un
texto en sus propios acuerdos de licencia. En dicho texto se hace
referencia a que la aplicación es "advertiser supported software", que
significa que algunos o todos los costes asociados al desarrollo y a
la distribución del producto intentan ser recuperados con el uso de
los anuncios visualizados a través del sistema Aureate incluido en la
aplicación. En las pruebas realizadas con diversas aplicaciones éste
apartado no se cumple en su totalidad y encontramos múltiples
irregularidades. En la mayoría de los casos, como por ejemplo CuteFTP
o GetRight, si bien se incluye alguna referencia a la tecnología de
Aureate al final del acuerdo de licencia del usuario, no se puede
encontrar el texto completo recomendado por la propia Aureate, que
explica con mayor detalle su funcionamiento.

En otras ocasiones, existen aplicaciones shareware que se ofrecen
durante un periodo de tiempo en modo completamente funcional, con las
mismas características que el usuario puede disfrutar al comprarlo.
Algunas distribuciones de este tipo incluyen el sistema Aureate, el
usuario no es informado durante la instalación, y la sorpresa llega
cuando Aureate se activa una vez pasado el periodo de prueba. La
responsabilidad en este caso particular recae sobre las casas
desarrolladoras que incluyen e instalan dicha tecnología sin informar
convenientemente al usuario.

A todas estas singularidades se suma la confusión que puede suponer el
hecho de que existan diferentes versiones y modalidades de incluir el
sistema Aureate en una aplicación. La más extendida es la que utiliza
la librería advert.dll, entre otras, -ya avanzo que hay versiones que
no incluyen dicha librería- basada en la construcción de un perfil del
usuario mediante la solicitud de información a través de formularios y
su identificación mediante un número personalizado. En este caso la
aplicación que pide la información al usuario es propiedad de Aureate,
y en todo momento se presenta con cumplida información sobre el uso
que se le va a dar a la misma.

Una vez hayamos instalado una aplicación que haga uso de Aureate el
resto de software que utilice el mismo sistema no tendrá que repetir
la solicitud de datos por formulario, ya que comparte el perfil
existente, por lo que puede dar la sensación de que estas aplicaciones
no advierten de modo adecuado al usuario. En otras versiones y
modalidades no existe solicitud de información adicional para la
creación del perfil, en esta ocasión el sistema de Aureate funciona de
forma similar a una cookie, si bien compartida entre todas las
aplicaciones que hagan uso de esta tecnología.

Es la propia Aureate la que solicita a los desarrolladores de software
que no incluyan sus librerías en los procesos de desinstalación a no
ser que estén totalmente seguros de que ningún otro software
instalado en el sistema hace uso de ellas. De lo contrario, si se
incluye en la desinstalación, puede suponer que al desinstalar un
programa dejen de funcionar el resto de aplicaciones que utilizaban y
compartían las librerías de Aureate (advert.dll, por ejemplo). La
práctica totalidad del software al que he tenido acceso sigue el
consejo de Aureate, lo que explica la existencia de las librerías aun
habiendo desinstalado la aplicación que hacía uso de ellas.

Este hecho no dejaría de ser una anécdota, sino fuera porque Aureate,
como se demostrará más tarde, utiliza a los navegadores para cargar
sus librerías en memoria, por lo que podemos encontrarnos en la
situación de haber desinstalado todo el software que hacía uso de las
aplicaciones y seguir con Aureate activado en memoria sin que el
usuario tenga ningún tipo de notificación al respecto ni hecho visible
para que pudiera percatarse de ello.

De esta forma queda empañada esta característica que en un principio
podría haberse interpretado como algo lógico, el pedir a los
desarrolladores no desinstalen el sistema de Aureate para facilitar la
compartición de librerías y perfil del usuario. Al mismo tiempo que
cobraría fuerza la idea de que pudiera actuar en un determinado
momento como si de un troyano se tratara al actuar al margen de lo que
se le presupone, ya que en ningún caso, y según la documentación a la
que he tenido acceso, se contempla esta característica.

Librerías y proceso de instalación

Las librerías de Aureate, entre otras advert.dll y la menos conocida
pero no menos importante amcis.dll, se instalan en el directorio de
sistema de Windows (system en Win9x y system32 en WinNT). El programa
de instalación verifica que no sobreescribe librerías ya existentes si
éstas son versiones superiores, para evitar así que la actualización
pueda afectar a software preinstalado que contemple características de
versiones más avanzadas. Las versiones superiores son compatibles con
las anteriores y, por tanto, las aplicaciones que fueron diseñadas
para trabajar con versiones antiguas del sistema Aureate funcionarán
de igual forma con las nuevas DLLs que ya se encuentran instaladas.

Otras consideraciones tienen que ver con los desarrolladores que
utilicen el componente AdvertX.ocx además de las DLLs. He podido
comprobar que la mayoría de las ocasiones suele incluirse en los
programas, que utilizan el sistema de Aureate y han sido desarrollados
con Visual Basic, aunque en realidad pueden ser utilizados con otros
lenguajes. El programador debe comprobar en esta ocasión que la
librería oleaut32.dll sea, como mínimo, la versión 2.20, ya que las
anteriores, distribuidas en las primeras versiones de Windows 95 y NT,
no contemplan el trabajo con componentes ActiveX. Aureate facilita una
versión actualizada de la librería oleaut32.dll para que pueda ser
distribuida en estos casos, teniendo especial cuidado, de nuevo, en no
sobreescribir versiones superiores.

Además de los mencionados podemos encontrar otros ficheros como parte
de la instalación de Aureate, y su inclusión o no depende de la
versión instalada: htmdeng.exe, ipcclient.dll, tfde.dll, raimage.dll,
adimage.dll, msipcsv.exe, Advert3.ocx, anadsc.ocx, advert203.ocx y
amcis2.dll.

Aureate en el Registro de Windows

A continuación hacemos un recorrido por las claves que Aureate
almacena en el registro de Windows y que nos proporciona información
imprescindible para poder entender su funcionamiento. En esta primer
apartado se pueden ver las que aparecen claramente vinculadas con
Aureate, al llevar su nombre en la clave. Más adelante veremos también
como se inserta en el registro información adicional que, sin llevar
una nomenclatura tan explícita, permitirá a Aureate ser cargado en
memoria cada vez que se lance el navegador de Microsoft o Netscape.

-HKEY_CLASSES_ROOT\Software\Aureate\Advertising
Bajo esta clave podemos encontrar las diferentes subclaves y valores
que Aureate almacena según configuración personalizada para nuestra
máquina.
-HKEY_CLASSES_ROOT\Software\Aureate\Advertising\Default Server
El valor "Address" contiene la dirección del servidor principal con el
que conectará, ejemplo "aim1.adsoftware.com". "Port" recoge el número
del puerto TCP para realizar la conexión, en las pruebas realizadas
siempre el 1975.
-HKEY_CLASSES_ROOT\Software\Aureate\Advertising\Servers
Nos podemos encontrar con una sucesión de subclaves que contienen los
mismos valores que la anterior (dirección y puerto) -obviamente con
diferentes datos-. Son usados Como servidores secundarios en caso de
que haya algún problema en la comunicación con el servidor por
defecto.
-HKEY_CLASSES_ROOT\Software\Aureate\Advertising\Distributors
En esta clave se almacena el valor "Distribuidor ID", numero de
identificación del distribuidor que se envía a los servidores de
Aureate y permite a los programadores hacer un seguimiento
personalizado de las estadísticas de publicidad que arrojan sus
aplicaciones según un ID específico.
-HKEY_CLASSES_ROOT\Software\Aureate\Advertising\Path
Contiene la ubicación de la librería ADVERT.DLL, que en un Windows 9x
puede ser "C:\WINDOWS\SYSTEM\ADVERT.DLL", por ejemplo.
-HKEY_CLASSES_ROOT\Software\Aureate\Advertising\Cookies
Espacio reservado para almacenar las cookies que provienen de los
servidores HTTP de los anunciantes. En las pruebas no se ha almacenado
ningún valor, y si en la clave del mismo nombre que se mantiene en
HKEY_CURRENT_USER que veremos a continuación.
-HKEY_CURRENT_USER\Software\Aureate\Advertising
Bajo esta clave se encuentran las subclaves que almacenan la
configuración para los usuarios específicos que utilizan la máquina.
En este apartado podemos encontrarnos con el valor "Proxy", y la
correspondiente URL que apunta al servidor y puerto, en los sistemas
que lo requieran para conectar a Internet, como por ejemplo en una red
local.
-HKEY_CURRENT_USER\Software\Aureate\Advertising\Cookies
Almacena las cookies según usuario, podemos encontrar subclaves con
los nombres de dominio de las cookies y en su interior valores que
almacenan el nombre de la cookie y su expiración.
-HKEY_CURRENT_USER\Software\Aureate\Advertising\Demographics
Aquí encontramos los valores de la "ficha" del usuario, según los
datos que hayamos suministrados en el formulario que Aureate nos
presenta cuando se instala por primera vez. ID del usuario, año de
nacimiento, sexo, trabajo, estado civil, nivel de estudios, país, etc.
Los datos que contienen estos valores corresponden siempre a los
suministrados en el formulario, Aureate no recopila y almecena
información por si sólo, aun en el caso de que lo hallamos dejado sin
rellenar, en blanco.
-HKEY_CURRENT_USER\Software\Aureate\Advertising\Demographics\Interests
Almacena los valores del formulario donde durante la instalación se
nos solicita que indiquemos nuestras áreas de interes, como por
ejemplo Automóviles, Educación, Libros/Revistas, Ordenadores, etc.
Toda esta información personalizada la utiliza para crear el perfil
que tiene como fin elegir que publicidad es la más adecuada para el
usuario.
-HKEY_LOCAL_MACHINE\Aureate\Advertesing
Durante las pruebas esta clave se creó pero nunca ha almacenado
información.
-HKEY_LOCAL_MACHINE\Aureate\Advertesing\Classes\Software\Aureate
Subclaves y valores equivalentes a los encontrados en HKEY_CLASSES_ROOT
-HKEY_USERS\Aureate\Advertesing
Subclaves y valores equivalentes a los encontrados en HKEY_CURRENT_USER

Funciones públicas de las librerías para los desarrolladores

Entre las acusaciones que se han barajado se encuentra la posibilidad
de que las aplicaciones que hicieran uso del sistema de Aureate
contaran con herramientas adicionales para actuar como troyano o
espiar a los usuarios. De entrada, esta afirmación carece de lógica,
ya que los desarrolladores pueden incluir, si quisieran, estas
características en su propio software sin tener que recurrir a
sistemas de terceros.

Para despejar cualquier duda al respecto se incluye a continuación las
principales funciones que las librerías de Aureate facilitan a los
desarrolladores que incorporan su sistema:

*debugTriggerEvent: sirve de ayuda para debuggear.
*GetStatus: devuelve diferentes estados para controlar los procesos.
*IsConnectOkay: permite conocer si la DLL ha sido capaz de comunicarse
con el servidor de publicidad.
*OnClick: se utiliza para detectar si el usuario hace click en el
banner y comprueba si se ha abierto la URL correspondiente en el
navegador por defecto.
*Paint: utilizado para llamar a la librería y visualice un banner en
la aplicación.
*RetryConnect: sirve para reiniciar el proceso de conexión, Aureate se
reinicia automaticamente cada vez que detecta algún problema en la
comunicación.
*SetAdRecordedCallback: avisa cuando el servidor de publicidad ha
registrado/contabilizado la visualización de un banner.
*SetBandwidthThrottle: permite configurar el máximo ancho de banda que
puede manejar la aplicación durante sus comunicaciones (por defecto
2Gb/sec.)
*SetCallback: comprueba si la llamada a visualizar un banner se ha
resuelto satisfactoriamente.
*SetMinimumAdDisplayTime: tiempo mínimo que se visualiza un banner
antes de llamar a otro.
*SetNetworkCallback: llamada después de que se intente hacer alguna
conexión con los servidores de publicidad.
*SetNetworkState: permite conocer si se está conectado a Internet.
*SetProxy: para poder configurar los valores de proxy HTTP en el
registro.
*Shutdown: destruye los procesos para cerrar la aplicación.
*Startup: para inicializar la librería.
*UseDefaultAd: llama, y permite configurar, el banner por defecto que
se visualizará en primer lugar y cuando existan problemas de
comunicación con el servidor para descargar nuevos banners.
Aureate facilita a los desarrolladores, que incorporan su sistema,
información adicional a través de un web en Internet, previa
identificación mediante usuario/contraseña, pero se limita a
proporcionar datos estadísticos sobre los banners visualizados a
través de su aplicación y la correspondiente compensación económica de
la que se benefician. En ningún caso el desarrollador tiene acceso a
información sensible de los usuarios.




Bernardo Quintero
bernardo@hispasec.com