jueves, 31 de julio de 2003

Contar máquinas detrás de un NAT

Aunque teóricamente no es posible hacerlo, un estudio reciente demuestra
la factibilidad de identificar máquinas y su tráfico asociado situadas
tras un NAT, o pasarela de traducción de direcciones de red.

El estudio publicado por Steve Bellovin, especialista en seguridad de
reconocido prestigio, demuestra cómo es posible asociar los datagramas
vistos en la cara pública del NAT (típicamente, Internet) con máquinas
individuales en la parte privada (típicamente, una LAN o red de área
local).

Esta identificación permite varias posibilidades, como el poder contar
el número de máquinas situadas tras el NAT (útil para un ISP que limita
el número de ordenadores que se pueden conectar por una línea) o
identificar tráfico y asociarlo a equipos en concreto.

En un sistema NAT clásico, cuando una máquina interna envía un datagrama
al exterior, el NAT lo reescribe poniendo su IP "pública" como remitente
del mismo, y un puerto origen arbitrario. Cuando llega un datagrama de
respuesta, se busca el puerto de destino (el puerto de origen arbitrario
de la frase anterior) en una tabla interna, obteniéndose el puerto
original y la IP interna a la que debe enviarlo.

La tecnología NAT se emplea, fundamentalmente, cuando es necesario
conectar una red LAN a Internet disponiendo de menos IPs públicas que
equipos internos. El equipo NAT se encarga de multiplexar las peticiones
internas entre las IPs y puertos públicos externos, permitiendo que toda
la LAN acceda a Internet sin necesitar una IP pública por equipo. Un NAT
puede proporcionar otros servicios, como cortafuegos o servidor de VPNs.

Tradicionalmente siempre se ha considerado que un NAT oculta el número,
la identidad y las características de la red LAN interna. Este estudio,
sin embargo, demuestra que no es así; los datagramas "traducidos"
conservan los suficientes rastros sin alterar como para que se pueda
identificar su origen. En concreto, todos los datagramas IPv4 contienen
un campo de 16 bits utilizado en el caso de que sea necesario
fragmentarlo en la ruta hacia su destino. Dicho campo permite que el
receptor identifique los distintos fragmentos de un datagrama y pueda
reensamblarlo de nuevo.

Aunque lo único que el protocolo IP requiere de dicho campo es que sea
único durante unos minutos, en la práctica la mayoría de las
implementaciones se limitan a utilizar un contador que se va
incrementando con cada datagrama enviado. Esto unido al hecho de que los
sistemas NAT suelen dejar este campo inalterado, como demuestra
Bellovin, permite asociar cada datagrama a una máquina interna concreta.

Las medidas a tomar son evidentes una vez que se identifica el problema:
el sistema NAT debe modificar el campo de identificación de los
datagramas que lo atraviesan (complicado) y, por otro lado, los sistemas
operativos usados en las máquinas internas deben generar los valores de
este campo de forma aleatoria o, al menos, no predecible para un
"escucha" externo (fácil). Los sistemas operativos "Open Source" OpenBSD
y FreeBSD ya han integrado dicha mejora en su código.

El documento, disponible en formato PDF, es una lectura llana, amena e
interesante. Recomendable


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


Más información:

Remotely Counting Machines Behind A NAT Box
http://slashdot.org/article.pl?sid=03/02/05/2129218

El documento en cuestión
http://www.research.att.com/~smb/papers/fnat.pdf

Parche OpenBSD
http://marc.theaimsgroup.com/?l=openbsd-cvs&m=104473518402730&w=2

Slashback: Regalia, Godseye, Undetection
http://slashdot.org/article.pl?sid=03/02/13/0048219

miércoles, 30 de julio de 2003

AMI comercializa una BIOS "Trusted Computing"

AMI (American Megatrends), uno de los fabricantes de BIOS para
ordenadores PC Compatibles más populares y difundidos en el mercado,
anuncia la disponibilidad de una BIOS que implementa la tecnología
"Trusted Computing".

La tecnología "Trusted Computing" pretende garantizar que se está
empleando una plataforma tecnológica (hardware y software) inalterada y
confiable. Para ello se realiza un proceso de verificación en varias
etapas.

En la primera etapa, al arrancar el ordenador, se verifica la integridad
de la BIOS (el sistema básico de arranque del ordenador) del sistema.
Una vez que la máquina determina que su BIOS es correcta y no ha sido
alterada, procede a cargar el bloque de arranque del sistema operativo.
Comprobada su autenticidad, éste procederá a lanzar el sistema
operativo, presumiblemente tras verificar también su identidad y
autenticidad.

La motivación "oficial" de la iniciativa "Trusted Computing" es asegurar
un entorno informático estable y confiable, evitando la propagación de
virus o troyanos, o la alteración no autorizada del equipo.
Presumiblemente las instalaciones "confiables" podrán acceder a recursos
informáticos adicionales, como servidores de licencias de software,
reproducción de contenidos multimedia de "pago", videojuegos, etc. En el
peor de los casos, si la BIOS no detecta un sistema operativo "de fiar",
se negará a funcionar.

En la práctica, y vista la experiencia de Microsoft con su consola XBOX
(un primer experimento de plataforma "Trusted Computing"), tenemos
serias dudas sobre sus motivaciones reales y, sobre todo, sobre su
seguridad real. Aunque técnicamente la tecnología permite determinar la
idoneidad del hardware y software que se está utilizando nada garantiza,
por ejemplo, que el software en cuestión no contenga agujeros de
seguridad que permitan lanzar programas arbitrarios en el sistema.
Adicionalmente, para un sistema informático es imposible saber si está
siendo ejecutado en un "entorno real" o está siendo "emulado" en una
máquina virtual. Dicha máquina virtual podría simular cualquier
componente del sistema, engañando cualquier intento de verificación.

En cualquier caso se trata de una iniciativa que vale la pena conocer,
aunque solo sea para ser consciente de sus limitaciones y meditar unos
minutos sobre sus posibilidades, tanto positivas como negativas.


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


Más información:

AMI Introduces 'Trusted Computing' BIOS
http://slashdot.org/article.pl?sid=03/01/09/166251

Press Release
AMIBIOS® enables secure and trusted computing with a TCPA-compliant
module
http://www.ami.com/news/pressshow.cfm?PrID=118

American Megatrends
http://www.ami.com/

martes, 29 de julio de 2003

Nueva versión del parche experimental para servidores virtuales Linux

Se publica una nueva versión del parche experimental para Linux que
permite el particionado del sistema operativo en entidades separadas e
independientes, posibilitando la creación de un número ilimitado de
"servidores virtuales" dentro de la misma máquina.

Cada servidor virtual puede tener una visión propia del sistema de
ficheros (vía "chroot" y "mount"), una IP separada (vía la nueva llamada
al sistema "set_ipv4root") y una lista de procesos independiente (vía la
nueva llamada al sistema "new_s_context"), para que los diferentes
servidores virtuales no puedan listar o acceder a procesos externos.

Con estas nuevas funcionalidades es posible crear servidores virtuales
arbitrarios, cada uno de ellos independiente de los demás y sin que se
produzcan interferencias entre los mismos, incluso para los
"superusuarios" o "root", o ejecutables SETUID.

Todas las máquinas virtuales se ejecutan bajo la misma imagen de sistema
operativo, por lo que su rendimiento es óptimo, y no se requiere ningún
cambio en las herramientas para hacer uso de esta nueva funcionalidad.

Otros Unix disponen de funcionalidades similares, como la función "jail"
de *BSD, pero el parche propuesto para Linux es más flexible y permite
posibilidades extra, como que el "super super usuario" (el usuario
"root" del dominio de seguridad "root") pueda añadir nuevos procesos a
un servidor virtual ya creado y en funcionamiento.

Además "new_s_context" es una llamada a sistema no privilegiada,
pudiendo ser utilizada por cualquier usuario. Por ejemplo, para
"encerrar" un proceso no fiable y que éste no pueda interactuar con
otros procesos del sistema, incluso del mismo usuario. "set_ipv4root"
tampoco es una llamada privilegiada.

Se trata de un parche experimental pero bastante robusto. Cualquier
administrador de sistemas Linux debería echarle un vistazo, sobre
todo si su trabajo está relacionado con el hospedaje de máquinas
y/o servicios.

La última versión del parche (0.23) funciona correctamente con la última
versión publicada del kernel estable de Linux, la 2.4.21.


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


Más información:

Virtual private servers and security contexts
http://www.solucorp.qc.ca/miscprj/s_context.hc

El código fuente
ftp://ftp.solucorp.qc.ca/pub/vserver

20/11/2001 - Parche experimental para servidores virtuales Linux
http://www.hispasec.com/unaaldia/1122

lunes, 28 de julio de 2003

Denegación de servicio a través de ataques de complejidad algorítmica

Investigadores de la universidad de Rice, en EE.UU., han propuesto y
demostrado un nuevo tipo de ataque de denegación de servicio (DoS),
efectivo contra un gran numero de servicios y tecnologías.

El ataque se basa en explotar vulnerabilidades algorítmicas en muchos de
los algoritmos empleados en el software a atacar. La idea clave del
ataque es que muchas de las estructuras de datos y algoritmos empleados
habitualmente, tienen un buen comportamiento en los casos "normales",
pero pueden degenerar a casos "críticos" (en consumo de memoria o de
CPU) antes situaciones "patológicas".

Un caso evidente es el "quicksort", o "clasificación rápida". Se trata
de un algoritmo descubierto a mediados de los años 60, y ampliamente
utilizado. De hecho, forma parte de la librería estándar de C. Se trata
de un algoritmo cuyo tiempo de ejecución en el caso "típico" es
prácticamente lineal con el número de elementos a ordenar. Pero en
situaciones patológicas, el tiempo de ejecución pasa a depender del
CUADRADO de elementos, lo que resulta desorbitado y peligroso.

Si el algoritmo empleado posee casos patológicos y estos son accesibles
para un atacante, es posible que dicho atacante consiga unos consumos de
memoria y/o CPU exagerados y logre obtener un DoS.

El artículo describe varios ataques contra programas muy utilizados en
Internet, incluyendo el propio kernel de Linux. La última versión del
kernel ya ha corregido el problema explotado.

Existen dos posibilidades para abordar el problema:

a) Emplear estructuras de datos o algoritmos que carezcan de casos
patológicos. Lamentablemente esta solución suele ser más compleja o
menos eficiente en el caso típico. En algunos casos incluso puede
no existir una alternativa práctica.

b) Evitar que un atacante pueda introducir valores patológicos. Por
ejemplo, en una tabla HASH, además de la clave de búsqueda que pueda
estar bajo el control del usuario, podemos usar un factor aleatorio,
que varía de forma periódica o que se genera al arrancar el programa,
para evitar que el usuario obtenga control total sobre la estructura
y pueda conducirla a situaciones límite.

En resumidas cuentas, se trata de un nuevo tipo de ataque, muy potente y
con gran potencial, aunque su efectividad depende precisamente de su
novedad. Es decir, a medida que se abuse de este tipo de ataque,
solucionarlo será muy simple, sobre todo si se opta por la segunda vía
de solución (incluir factores no predecibles por el atacante). La parte
negativa es que, en la mayoría de los casos, los programas vulnerables
deberán corregirse uno a uno. No hay balas de plata ni varitas mágicas.

Otro riesgo importante de este ataque es que muchos programadores,
aunque reconocen que sus productos son vulnerables, ven las
posibilidades de ataque como "remotas", en el mejor de los casos. Un
ejemplo es el lenguaje de programación Python, para el que sus
desarrolladores han anunciado ya que no van a solucionar el problema...
mientras no sea un problema real.

Mi opinión personal es que sí se trata de un problema grave y cuyo
alcance es inconmensurable, si bien solucionar cualquier incidencia del
mismo en la práctica debería ser un proceso rápido y casi trivial.


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


Más información:

Denial of Service via Algorithmic Complexity Attacks
http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/index.html

Denial of Service via Algorithmic Complexity Attacks
http://www.cs.rice.edu/~scrosby/hash/

Denial of Service via Algorithmic Complexity Attacks
http://catless.ncl.ac.uk/Risks/22.76.html#subj12

26/05/2003 - Ataque DoS sobre el sistema operativo Linux
http://www.hispasec.com/unaaldia/1674

15/06/2003 - Se publica el kernel Linux 2.4.21
http://www.hispasec.com/unaaldia/1694

domingo, 27 de julio de 2003

Predicen gusano tras la publicación de un exploit

La publicación del código de un programa que aprovecha una reciente
vulnerabilidad de Windows, para conseguir el control total de los
sistemas afectados, desata la polémica en los foros de seguridad.
Mientras que algunos predicen que será inminente la aparición de
algún gusano de propagación masiva (tipo "Nimda" o "Slammer")
aprovechando los detalles del exploit publicado, otros defienden
que esta forma de actuar es beneficiosa para la seguridad.

El debate no es nuevo, los pros y contras del "full disclosure"
(divulgación total en materia de seguridad informática) suele ser un
tema recurrente en los foros de seguridad. Además de la repercusión
directa sobre la seguridad de nuestros sistemas, la realidad es que
suelen existir intereses paralelos por parte de las empresas afectadas
y los expertos o hackers que publican exploits. Más información, y mi
opinión al respecto, puede encontrarse en el una-al-día "La trastienda
del full disclosure" (http://www.hispasec.com/unaaldia/1257).

En el caso que nos ocupa, el exploit ha sido publicado por un grupo
chino 9 días después de que Microsoft hiciera lo propio con el
boletín de seguridad que avisa sobre la vulnerabilidad y pusiera a
disposición el parche para corregir los sistemas afectados. Los
detalles sobre la vulnerabilidad y el parche de Microsoft pueden
ser consultados en el una-al-dia "Desbordamiento de búfer en interfaz
RPC de sistemas Windows" (http://www.hispasec.com/unaaldia/1728).

En teoría ha existido suficiente tiempo para que los usuarios hayan
actualizado sus sistemas. La realidad es bien diferente, a nadie
escapa que los usuarios finales no suelen instalar los parches
puntualmente, o las dificultades que entraña mantener actualizado un
parque de cientos o miles de máquinas en un entorno corporativo.

A raíz de la publicación de esta primera prueba de concepto para
explotar la vulnerabilidad, que sólo funcionaba en 3 versiones de
Windows, otro hacker ha optimizado el exploit y ha publicado una
nueva versión que permite su uso en al menos 7 versiones de Windows,
incluyendo desde Windows 2000 (desde su primera versión hasta con el
Service Pack 4) y Windows XP con o sin el Service Pack 1.

Los peligros que se pueden derivar de la publicación de estos códigos
parecen evidentes, desde el ya anunciado posible diseño de un gusano
que se reproduzca e infecte automáticamente a través de Internet y
redes locales, hasta la aparición de herramientas ya compiladas y
listas para usar que permiten a cualquiera atacar a los sistemas con
un simple click de ratón (desde Hispasec ya hemos podido ver al
menos a una herramienta de este tipo y es previsible que aparezcan
algunas más durante los próximos días).

En el apartado de beneficios, la publicación de los detalles de estos
códigos también puede ser aprovechada por los expertos de seguridad
y administradores de sistema. Un ejemplo obvio son las firmas y
patrones para los IDS/IPS (sistemas de detección y prevención de
intrusiones) que se han construido a raíz de estos exploits, y que
permite a los sistemas y empresas que cuenten con estos sistemas
estar protegidos ante este ataque y posiblemente ante un gusano que
aprovechara estos códigos.

La aparición de un gusano es de momento una incógnita que puede
que tarde meses en resolverse. En el caso del gusano "Slammer"
la infección comenzó 6 meses después de la aparición del exploit
para la vulnerabilidad de MS-SQL, si bien el gusano "Code Red" entró
en escena apenas un mes de publicarse los detalles del exploit
para el servidor web de Microsoft.

Desde Hispasec recomendamos la instalación inmediata de los parches
proporcionados por Microsoft, que si antes eran críticos ahora ya
son de máxima urgencia. Además de los IDS/IPS, el bloqueo del tráfico
RPC en los firewalls perimetrales (tcp/135) prevendrá de posibles
ataques externos y probablemente de la acción de un gusano de
propagación masiva a través de Internet que aproveche esta
vulnerabilidad.


Bernardo Quintero
bernardo@hispasec.com


Más información:

Microsoft Windows 2000 RPC DCOM Interface DOS AND Privilege Escalation Vulnerability
http://www.xfocus.org/advisories/200307/4.html

Win32 DCOM RPC Exploit
http://www.metasploit.com/releases.html
http://www.metasploit.com/tools/dcom.c

Hacker code could unleash Windows worm
http://news.com.com/2100-1002_3-5055759.html?tag=cd_mh

Group posts code to exploit Windows flaw
http://www.globetechnology.com/servlet/story/RTGAM.20030726.wflaw0726/BNStory/Technology/

sábado, 26 de julio de 2003

Vulnerabilidades en servidores Apple QuickTime/Darwin Streaming 4.1.x

Se han identificado múltiples vulnerabilidades en el servidor de
streaming Darwin que pueden permitir a un atacante provocar
denegaciones de servicio o el acceso a información sensible.

En estos momentos existen versiones de este servido para plataformas
Mac OS X, Linux, Solaris y Windows NT/2000.

1) Es posible provocar una denegación de servicio mediante la petición
de un nombre de dispositivo DOS, ej. "GET /AUX" o "GET /../AUX". Esto
solo afecta a sistemas Microsoft Windows.

2) Es posible provocar una denegación de servicio mediante la petición
de "/view_broadcast.cgi" a través de HTTP en el puerto 1220/tcp. Esto
solo afecta a sistemas Microsoft Windows.

3) Es posible visualizar el código fuente de cualquier archivo
mediante "/parse_xml.cgi?filename=nombre_de_archivo" a través de HTTP.

4) Es posible visualizar el código fuente de cualquier script
añadiendo "%2e" y "%20" al nombre del script al realizar la petición
HTTP.

5) Es posible visualizar cualquier archivo fuera de la raíz del web
usando una escalada de directorios trivial en peticiones HTTP. Ej.
"GET /../qtusers".

6) Un usuario malicioso podrá configurar la contraseña de admin si el
sistema está conectado a Internet antes de que sea correctamente
configurado. El problema es que "Setup Assistant" está disponible para
cualquier usuario hasta que el sistema esté configurado. Esto solo
afecta en sistemas Mac OS X.

Todos los problemas (excepto el 3) están corregidos en la versión
4.1.3g.

http://developer.apple.com/darwin/projects/streaming/

Como contramedida para el problema 3 solo se puede eliminar el archivo
"parse_xml.cgi" hasta que se publique una actualización.


Antonio Román
roman@hispasec.com


Más información:

Multiple Vulnerabilities Apple QuickTime/Darwin Streaming Server
http://www.rapid7.com/advisories/R7-0015.html

Streaming Server
http://developer.apple.com/darwin/projects/streaming/

viernes, 25 de julio de 2003

Desbordamiento de búfer en motor Microsoft Jet

Se ha anunciado una vulnerabilidad en Microsoft JET Engine, que puede
ser explotada por un usuario malicioso para elevar sus privilegios en
los sistemas vulnerables.

La vulnerabilidad está provocada por un búfer sin comprobar cuando se
incluye un nombre de función muy largo (276 caracteres o más) en una
consulta SQL. Esto provoca el desbordamiento de búfer y permite la
ejecución de código arbitrario con privilegios elevados.

Ejemplo:
SELECT * FROM
OPENROWSET('microsoft.jet.oledb.4.0','c:\basedatos.mdb';'admin';'','se
lect XXX...[276]...XXX()')

La vulnerabilidad afecta a todo el software que haga uso del motor
Microsoft JET 4.0 con SP6 aplicado, aunque anteriores versiones
también pueden estar afectadas. Otros productos de Microsoft que
heredan la vulnerabilidad son Access 2000, Access 2002, MDAC 2.x,
Office 2000, Office XP, SQL Server 2000 y SQL Server 7.

La vulnerabilidad se ha solucionado en Microsoft JET Service Pack 7
incluido en Windows 2000 Service Pack 4 que se encuentra disponible en
disponible en:
http://www.microsoft.com/windows2000/downloads/servicepacks/sp4/default.asp

La instalación de Service Pack 7 para JET en otros sistemas debe
llevarse a cabo a través de Windows Update o desde las siguientes
direcciones:
Windows NT 4.0:
http://download.microsoft.com/download/e/8/c/e8c5729c-d90a-4d15-bdc1-cbc9eae82924/Jet40SP7_9xNT.exe
Windows ME:
http://download.microsoft.com/download/f/e/f/fefd6ea9-e5d8-4edf-810d-924f7d1d2de4/Jet40SP7_WMe.exe


Antonio Ropero
antonior@hispasec.com


Más información:

The Updated Version of Microsoft Jet 4.0 Is Available in the Download
Center
http://support.microsoft.com/default.aspx?scid=kb;EN-US;239114
http://support.microsoft.com/default.aspx?scid=kb;EN-US;282010

[Full-Disclosure] Microsoft JET Database Engine 4.0 buffer overflow
http://lists.netsys.com/pipermail/full-disclosure/2003-July/011193.html

jueves, 24 de julio de 2003

Las contraseñas NTLM son inseguras (por si alguien todavía no lo sabía)

Un investigador presenta un nuevo algoritmo para identificar
las contraseñas a partir del sus correspondientes hashes de forma muy
rápida: en 13,6 segundos de media se puede identificar cualquier contraseña
compuesta de caracteres numéricos y alfanuméricos.

El pasado martes 22 de julio, un investigador suizo publicó un
artículo donde presentaba un nuevo método para romper las contraseñas
utilizadas por Windows. El nuevo método se demuestra como uno de los
sistemas más rápidos para romper contraseñas, ya que de media sólo
necesita 13,6 segundos. Eso si, únicamente si la contraseña está
compuesta totalmente por caracteres alfabéticos (a-z y A-Z) y
numéricos (0-9).

El método consiste en almacenar tablas de referencia de gran tamaño
que permiten asociar las posibles contraseñas con el texto introducido
por los usuarios, lo que permite acelerar todas las operaciones
matemáticas necesarias para romper la contraseña. Esto implica que
para poder realizar la identificación es necesario tener acceso a un
ordenador con una gran cantidad de memoria: entre 1,5 y 2 GB... lo que
hoy en día no es nada del otro mundo. Además también son necesarias
gran cantidad de datos que puedan utilizarse como valores de
referencia, con sus correspondientes códigos hash.


La investigación ha tomado como referencia las contraseñas de Windows,
codificadas de acuerdo con el proceso de autenticación NTLM debido a
la facilidad con que puede accederse a un volumen de información tal
que facilita la realización de este estudio. No es por tanto un
análisis que tenga como objetivo mostrar la debilidad de NTLM, aunque
el investigador no puede dejar de decir, en vista a los resultados,
que el mecanismo de almacenamiento de contraseñas de Windows deja
bastante que desear.

Para demostrar la funcionalidad del ataque, se ha publicado una web en
la que podemos introducir cualquier código hash. El ordenador realiza
los cálculos para romper el código y nos avisa por correo electrónico
cuando consigue hacerlo.

No obstante, este nuevo sistema de identificación de contraseñas no
deja de ser una curiosidad matemática, con pocos efectos sobre la
seguridad informática. En primer lugar por que hoy en día ningún
administrador responsable tiene configurados sus sistemas para
utilizar la autenticación NTLM.

Pero incluso en el supuesto de que se continúen utilizando el
mecanismo de autenticación NTLM el sistema presentado únicamente es
efectivo si disponemos de acceso a los códigos hash de las
contraseñas. Para obtener estos hash tenemos que acceder bien
físicamente a la SAM de la máquina NT donde están almacenadas (que
seguramente está cifrada con syskey).

Si deseamos realizar un ataque online, deberemos tener privilegios de
administrador (o bien obtenerlo) para poder obtener los hashes del
controlador de dominio. Si ya somos administrador, poco interés
tenemos en capturar e identificar las contraseñas; no las necesitamos.


Xavier Caballé
xavi@hispasec.com


Más información:

Making a Master Cryptanalytic Time-Memory Trade-Off
http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf

Advanced Instant NT Password Cracker
http://lasecpc13.epfl.ch/ntcrack/

About Windows Passwords and the Time-Space Trade-Off
http://www.cryptonomicon.net/modules.php?name=News&file=article&sid=410

Crack Passwords in Seconds! Not.
http://www.e2ksecurity.com/archives/000409.html

Nou mètode per a la identificació ràpida de contrasenyes NTLM
http://www.quands.info/articles/html/ntlm-pwd.html

Cracking Windows passwords in seconds
http://news.com.com/2100-1009_3-5053063.html?tag=fd_lede2_hed

How to prevent Windows from storing a LAN Manager hash of your
password in Active Directory and Local SAM databases
http://support.microsoft.com/support/kb/articles/q299/6/56.asp

Windows NT System Key Permits Strong Encryption of ge SAM
http://support.microsoft.com/support/kb/articles/q143/4/75.asp

miércoles, 23 de julio de 2003

Nuevo Apache 1.3.28

La fundación Apache acaba de publicar la versión 1.3.28 de su servidor
web, que soluciona varios problemas de seguridad importantes.

Apache es el servidor web más popular del mundo, disponible en código
fuente y para infinidad de plataformas, incluyendo UNIX, Microsoft
Windows, OS/2 y Novell NetWare.

Además de solucionar numerosos "bugs", se han eliminado también los
siguientes problemas de seguridad:

* Bajo Microsoft Windows y OS/2 se ha eliminado un DoS (ataque de
denegación de servicio) sobre "rotatelogs". Explotado, el ataque
permite detener la grabación de logs.

* Se ha eliminado una posibilidad de DoS sobre el servidor, limitando
el número de redirecciones internas y subpeticiones.

* Tratamiento más seguro de los descriptores de ficheros accesibles
a procesos externos, como CGI's.

* Se elimina la posibilidad de caídas o retardos en el procesado
de nuevas conexiones cuando se eliminaba un proceso Apache hijo.

* Solucionadas algunas posibilidades de desbordamiento de búfer
en "htdigest".

* Mejor tratamiento en la gestión de la terminación de subprocesos.

La recomendación es que todos los administradores de servidores Apache
1.3.* actualicen a la versión 1.3.28. Las instalaciones 2.0.* no
requieren actualización.


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


Más información:

Changes with Apache 1.3.28
http://www.apache.org/dist/httpd/CHANGES_1.3

Apache 1.3.28 Released
http://www.apache.org/dist/httpd/Announcement.html

Apache HTTP Server Project
http://httpd.apache.org/

Apache HTTP Server Source Code Distributions
http://www.apache.org/dist/httpd/

martes, 22 de julio de 2003

Comparativas y certificaciones antivirus

Hispasec ultima los detalles de un nuevo sistema de control antivirus
que ofrecerá indicadores inéditos hasta la fecha. El nuevo servicio
permitirá evaluar algunos aspectos de los diferentes productos de
forma continua e ininterrumpida (24hx7d), marcando el inicio de una
nueva serie de exhaustivas comparativas.

Son muchos los usuarios y profesionales que durante los últimos
tiempos nos han consultado sobre la publicación de una nueva edición
on-line de nuestra comparativa antivirus. Si bien es cierto que en
la web sólo se encuentran accesibles las comparativas 1999, 2000 y
2001, durante estos dos últimos años el laboratorio de Hispasec
Sistemas ha seguido realizando a demanda pruebas técnicas y tests
para diversas comparativas de publicaciones del sector (PC Actual,
PC World, Computer Hoy, Computer Idea, Personal Computer & Internet,
etc.).

Algunos hitos que han marcado estas comparativas han sido el empleo
de múltiples colecciones de muestras reales, el uso de entornos reales
con la instalación de una red para evaluar la protección en diferentes
ambientes y servicios Internet, el diseño de virus de laboratorio para
evaluar los tiempos de reacción y respuesta de las diferentes casas
antivirus en crear la vacuna, la inclusión de tests de detección
inéditos (virus falsos, formatos de autodescompresores ejecutables,
...), medición del impacto de los productos en el rendimiento del
sistema, o la evaluación de los servicios de atención al usuario.

Pese a la continua innovación que ha sufrido las comparativas de
Hispasec durante estos años, marcando diferencias con aquellas
otras comparativas y certificaciones que únicamente se basan en
porcentajes de detección de colecciones ITW o ZOO, existen algunas
lagunas que hasta la fecha ningún otro estudio ha abordado:

* Los tests de las comparativas y certificaciones actuales se
realizan de forma puntual (ya sea una vez al año o cada "x" meses),
por lo tanto no pueden detectar irregularidades o defectos que
se localizan durante el tiempo que transcurre entre las comparativas.
Uno de los casos típicos son las actualizaciones del motor o el
archivo de firmas que provocan un mal funcionamiento o que algunos
antivirus dejen de detectar ciertos virus.

* Los tests se llevan a cabo con colecciones privadas (especialmente
las ZOO) que no son representativas de las muestras reales que
afectan a los usuarios y por tanto pueden ofrecer resultados
parciales y de poco valor práctico.

* Se excluye a los usuarios, profesionales, empresas y organismos
en la participación activa de los tests, cuya metodología además
suele quedar oculta a la revisión pública.

* Las comparativas y certificaciones actuales no evalúan el
comportamiento de los productos antivirus en momentos críticos.
Por ejemplo, dada la aparición de un espécimen de alta propagación
que cause una epidemia significativa, no existen hoy por hoy
mecanismos que evalúen de forma objetiva la respuesta de cada
casa y producto antivirus.

Estos y otros defectos intrínsecos de los esquemas de evaluación
actuales serán solventados por el nuevo servicio que entrará
en producción después del verano, marcando el inicio de los
tests de la nueva comparativa antivirus de Hispasec que será
accesible de forma pública desde nuestra web.


Bernardo Quintero
bernardo@hispasec.com


Más información:

03/02/2003 - Antivirus: el efecto "zoo"
http://www.hispasec.com/unaaldia/1562

24/07/2002 - Certificaciones antivirus obsoletas
http://www.hispasec.com/unaaldia/1368

Comparativa antivirus 2001
http://www.hispasec.com/directorio/laboratorio/articulos/Comparativa2001

Comparativa antivirus 2000
http://www.hispasec.com/directorio/laboratorio/articulos/Comparativa2000

Comparativa antivirus 1999
http://www.hispasec.com/directorio/laboratorio/articulos/Comparativa1999

lunes, 21 de julio de 2003

Proyecto CCured

El proyecto CCured permite reducir e incluso eliminar los riesgos de
seguridad que suponen los desbordamientos de búfer, plaga de nuestros
días.

El proyecto CCured, desarrollado en la universidad de Berkeley, se basa
en la traducción automática de un código fuente en lenguaje C en otra
versión del programa que contiene las comprobaciones de seguridad
necesarias para evitar los desbordamientos de búfer. Ese segundo
programa será el que se compile para obtener el producto final.

Dado que la traducción es automática, el coste de implementar esta
tecnología es muy bajo. A nivel de rendimiento, la sobrecarga que
suponen las comprobaciones adicionales disminuyen el rendimiento del
software entre un 10% y un 60%, dependiendo de la aplicación concreta.
Adicionalmente, el programador puede alterar el código original para
facilitar el trabajo a CCured y mejorar el rendimiento.

Existen proyectos similares desde hace tiempo, como la comprobación del
tamaño de las matrices en el compilador GCC, pero éste parece ser el
primer intento serio, sistemático y multiplataforma por reducir el
problema genérico de desbordamiento de búfer. CCured, en realidad,
protege contra otros usos incorrectos de punteros, como intentar acceder
a través de un "NULL", usar punteros para acceder a objetos
incompatibles, etc.

Lamentablemente estos problemas de seguridad son inherentes al diseño
del lenguaje C. Considerando que existen otros lenguajes bastante
difundidos, más productivos e igualmente eficientes para el desarrollo
de aplicaciones informáticas, el problema -en última instancia- es
cultural y de inercia tecnológica.

En cualquier caso, proyectos como CCured son muy interesantes, por
ejemplo, para proteger la gran cantidad de código C actualmente en uso
en el mundo de la informática.


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


Más información:

CCured Documentation
http://manju.cs.berkeley.edu/ccured/

domingo, 20 de julio de 2003

Problemas de seguridad en routers ADSL Asus

Se han anunciado vulnerabilidades en routers ADSL Asus (AAM6000EV y
AAM6330BI), que puede ser explotada remotamente por un atacante con el
fin de conseguir información sensible del ordenador atacado.

Para que el acceso al router se vea afectado por la vulnerabilidad en
cuestión es necesario que esté activado el servidor web integrado,
esto facilitará a un atacante hacerse con la lista de usuarios y
contraseñas almacenadas sin cifrar.

Las vulnerabilidades están provocadas por un error en el control de
acceso cuando el servidor web integrado está habilitado. Cualquier
usuario desde la LAN puede acceder a los recursos "userdata" y
"snmpinit", que pueden mostrar la lista de nombres de usuarios y
contraseñas en texto plano así como las cadenas de comunidad SNMP.

Ejemplos:
http://[victima]/userdata
http://[victima]/snmpinit

Se recomienda deshabilitar el servidor web integrado o restringir su
acceso.


Antonio Román
roman@hispasec.com


Más información:

Asus ADSL Router Information Disclosure Vulnerability
http://www.securityfocus.com/bid/8183

sábado, 19 de julio de 2003

Vulnerabilidad DoS en dispositivos Cisco

Todos los dispositivos Cisco que utilicen IOS y acepten tráfico IPv4
son susceptibles a un ataque de denegación de servicio (DoS),
explotable de forma remota. Los dispositivos vulnerables atacados
dejarán de procesar el tráfico de la red.

Todos los swicthes y routers del fabricante Cisco que ejecutan el
software IOS (Internetwork Operating System) y acepten el tráfico IPv4
son vulnerables a un ataque de denegación de servicio provocado por un
error en las funciones encargadas de procesar los paquetes de
determinados protocolos TCP/IP: 53 (SWIPE), 55 (IP Mobility), 77 (Sun
ND) y 103 (PIM)

Cuando un dispositivo vulnerable recibe una serie de paquetes
especialmente formateados e identificados con los tipos de protocolos
indicados anteriormente, debido a la existencia de una vulnerabilidad,
el sistema queda totalmente bloqueado. El interfaz que ha recibido los
paquetes queda totalmente deshabilitado y el dispositivo detiene
cualquier función de proceso de paquetes. En ningún momento se emite
una alarma que pueda avisar a los administradores del ataque y la
acción de reiniciar el dispositivo no permitirá que éste vuelva a ser
operativo.

Además, está circulando un exploit que utiliza esta vulnerabilidad,
por lo que es especialmente importante que los administradores de
dispositivos Cisco con IOS y que utilicen el protocolo IPv4 en sus
redes (el protocolo comúnmente utilizado en prácticamente todas las
redes TCP/IP) consulten urgentemente el boletín publicado por Cisco
para instrucciones especificas sobre la disponibilidad de versiones
actualizadas del IOS que solucione este problema. En caso de no
aplicar la actualización, la red estará expuesta a quedar totalmente
inoperativa en el supuesto de recibir el ataque.

Para detectar si un dispositivo Cisco es vulnerable a este
vulnerabilidad, Foundstone ha publicado una herramienta (SNScan) que
informa, de una forma fácilmente comprensible, si un dispositivo en
particular es vulnerable al problema.


Xavier Caballé
xavi@hispasec.com


Más información:

Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 Packet
http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml

Bloqueo de interfaces en dispositivos con IOS Cisco a través de paquets IPv4
http://www.unam-cert.unam.mx/Boletines/Boletines2003/boletin-UNAM-CERT-2003-015.html

Aviso del CERT CA-2003-15
Cisco IOS Interface Blocked by IPv4 Packet
http://www.cert.org/advisories/CA-2003-15.html

Cert Vulnerability Note #411332
Cisco IOS Interface Bloked by IPv4 Packet
http://www.kb.cert.org/vuls/id/411332

Exploit disponible para vulnerabilidad en la interfaz de Cisco IOS
http://www.unam-cert.unam.mx/Boletines/Boletines2003/boletin-UNAM-CERT-2003-017.html

Aviso del CERT CA-2003-17
Exploit available for the Cisco IOS Interface Blocked Vulnerabilities
http://www.cert.org/advisories/CA-2003-17.html

SNScan 1.05
http://www.foundstone.com/resources/proddesc/snscan.htm

viernes, 18 de julio de 2003

Desbordamiento de búfer en interfaz RPC de sistemas Windows

Se ha anunciado la existencia de una vulnerabilidad en la
implementación RPC de algunos sistemas Windows a través de la cual
un atacante puede lograr la ejecución de código.

Remote Procedure Call (RPC) es un protocolo empleado por los sistemas
operativos Windows para proporcionar mecanismos de comunicación entre
procesos de forma que un programa que se ejecute en un sistema pueda
ejecutar código en un sistema remoto de forma transparente. La
implementación de Microsoft de este protocolo está derivada del
protocolo RPC de la OSF (Open Software Foundation) pero con la
inclusión de algunas extensiones específicas de Microsoft.

El protocolo RPC se utiliza para que un programa pueda ejecutar código
en un ordenador remoto. Por ejemplo, se utiliza el protocolo RPC para
la compartición de las impresoras de una red. En el caso de Windows,
el servicio RPC está asociado al puerto 135/tcp."

Existe una vulnerabilidad en la parte de RPC que negocia con el
intercambio de mensajes sobre TCP/IP. El fallo resulta provocado por
un tratamiento incorrecto de mensajes mal construidos. Esta
vulnerabilidad en particular afecta al interfaz DCOM (Distributed
Component Object Model) con RPC, que escucha en el puerto TCP/IP 135.
Este interfaz trata la petición de activación de objetos DCOM enviadas
por las máquinas cliente al servidor (como rutas UNC).

Para explotar esta vulnerabilidad, un atacante debe enviar peticiones
especialmente mal construidas al sistema remoto a través del puerto
135. Se ven afectadas por este problema Windows NT 4.0, Windows NT 4.0
Terminal Services Edition, Windows 2000, Windows XP y Windows Server
2003.

En Windows, a diferencia de los sistemas *nix, no existe una forma
fácil de deshabilitar este protocolo. Por lo tanto, la medida de
protección más efectiva es el bloqueo del tráfico mediante cortafuegos
u otras medidas de protección perimetral

Las actualizaciones publicadas por Microsoft para evitar este problema
pueden descargarse desde:
Windows NT 4.0 Server
http://microsoft.com/downloads/details.aspx?FamilyId=2CC66F4E-217E-4FA7-BDBF-DF77A0B9303F&displaylang=en
Windows NT 4.0 Terminal Server Edition
http://microsoft.com/downloads/details.aspx?FamilyId=6C0F0160-64FA-424C-A3C1-C9FAD2DC65CA&displaylang=en
Windows 2000
http://microsoft.com/downloads/details.aspx?FamilyId=C8B8A846-F541-4C15-8C9F-220354449117&displaylang=en
Windows XP 32 bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=2354406C-C5B6-44AC-9532-3DE40F69C074&displaylang=en
Windows XP 64 bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=1B00F5DF-4A85-488F-80E3-C347ADCC4DF1&displaylang=en
Windows Server 2003 32 bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=F8E0FF3A-9F4C-4061-9009-3A212458E92E&displaylang=en
Windows Server 2003 64 bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=2B566973-C3F0-4EC1-995F-017E35692BC7&displaylang=en


Antonio Ropero
antonior@hispasec.com


Más información:

Buffer Overrun In RPC Interface Could Allow Code Execution (823980)
http://www.microsoft.com/technet/security/bulletin/MS03-026.asp

What You Should Know About Microsoft Security Bulletin MS03-026
http://www.microsoft.com/security/security_bulletins/MS03-026.asp

Buffer Overrun in Windows RPC Interface
http://lsd-pl.net/special.html

CERT® Advisory CA-2003-16 Buffer Overflow in Microsoft RPC
http://www.cert.org/advisories/CA-2003-16.html

jueves, 17 de julio de 2003

Paquetes actualizados de Xpdf para Red Hat Linux

Se publican paquetes actualizados de Xpdf para cubrir una
vulnerabilidad por la que un documento PDF malicioso puede llegar a
ejecutar código arbitrario.

Anteriormente se publicaron paquetes para cubrir esta misma
vulnerabilidad por la que uUn atacante puede incluir enlaces externos
maliciosos de forma que si estos se activan o la víctima accede a
ellos se podrá ejecutar comandos del shell arbitrarios. Sin embargo,
los paquetes anteriores no corregían todas las posibles formas de
explotar la vulnerabilidad.

Paquetes actualizados:

Red Hat Linux 7.1:

SRPMS:
ftp://updates.redhat.com/7.1/en/os/SRPMS/xpdf-0.92-4.71.2.src.rpm

i386:
ftp://updates.redhat.com/7.1/en/os/i386/xpdf-0.92-4.71.2.i386.rpm

Red Hat Linux 7.2:

SRPMS:
ftp://updates.redhat.com/7.2/en/os/SRPMS/xpdf-0.92-10.src.rpm

i386:
ftp://updates.redhat.com/7.2/en/os/i386/xpdf-0.92-10.i386.rpm

ia64:
ftp://updates.redhat.com/7.2/en/os/ia64/xpdf-0.92-10.ia64.rpm

Red Hat Linux 7.3:

SRPMS:
ftp://updates.redhat.com/7.3/en/os/SRPMS/xpdf-1.00-7.src.rpm

i386:
ftp://updates.redhat.com/7.3/en/os/i386/xpdf-1.00-7.i386.rpm
ftp://updates.redhat.com/7.3/en/os/i386/xpdf-chinese-simplified-1.00-7.i386.rpm
ftp://updates.redhat.com/7.3/en/os/i386/xpdf-chinese-traditional-1.00-7.i386.rpm
ftp://updates.redhat.com/7.3/en/os/i386/xpdf-japanese-1.00-7.i386.rpm
ftp://updates.redhat.com/7.3/en/os/i386/xpdf-korean-1.00-7.i386.rpm

Red Hat Linux 8.0:

SRPMS:
ftp://updates.redhat.com/8.0/en/os/SRPMS/xpdf-1.01-12.src.rpm

i386:
ftp://updates.redhat.com/8.0/en/os/i386/xpdf-1.01-12.i386.rpm
ftp://updates.redhat.com/8.0/en/os/i386/xpdf-chinese-simplified-1.01-12.i386.rpm
ftp://updates.redhat.com/8.0/en/os/i386/xpdf-chinese-traditional-1.01-12.i386.rpm
ftp://updates.redhat.com/8.0/en/os/i386/xpdf-japanese-1.01-12.i386.rpm
ftp://updates.redhat.com/8.0/en/os/i386/xpdf-korean-1.01-12.i386.rpm

Red Hat Linux 9:

SRPMS:
ftp://updates.redhat.com/9/en/os/SRPMS/xpdf-2.01-11.src.rpm

i386:
ftp://updates.redhat.com/9/en/os/i386/xpdf-2.01-11.i386.rpm
ftp://updates.redhat.com/9/en/os/i386/xpdf-chinese-simplified-2.01-11.i386.rpm
ftp://updates.redhat.com/9/en/os/i386/xpdf-chinese-traditional-2.01-11.i386.rpm
ftp://updates.redhat.com/9/en/os/i386/xpdf-japanese-2.01-11.i386.rpm
ftp://updates.redhat.com/9/en/os/i386/xpdf-korean-2.01-11.i386.rpm



Antonio Ropero
antonior@hispasec.com



miércoles, 16 de julio de 2003

Vulnerabilidad en StoreFront 6.x y anteriores

Recientemente se ha dado a conocer una vulnerabilidad en StoreFront 6
y anteriores por la que un atacante podría tener acceso no autorizado
a información de usuarios legítimos.

StoreFront es un sistema de carro de compra para comercio electrónico
desarrollado sobre ASP. El sistema en sí pretende ser un interfaz
completo para comercio electrónico.

La vulnerabilidad en sí, está causada por una falta de validación en "login.asp", lo que permitirá a un atacante remoto explotar el problema mediante inyección de código SQL. Con esto el intruso conseguirá saltarse la validación del usuario legítimo.

Ejemplo:

Email del usuario registrado: ejemplo@ejemplo.com

Email id (usuario en login.asp): ejemplo@ejemplo.com

Password: ' or 'a'='a


Antonio Román
roman@hispasec.com


Más información:

Storefront sql injection: users info disclosure
http://www.zone-h.org/en/advisories/read/id=2684/

martes, 15 de julio de 2003

Migmaf, un troyano que convierte los PCs en servidores de páginas pornográficas

A finales de la semana pasada teníamos conocimiento de un nuevo
troyano. Si bien su distribución es casi anecdótica, destaca por
instalar un proxy reverso en el ordenador infectado que redirecciona
las peticiones HTTP contra un servidor central, habitualmente con
contenido pornográfico. De esta forma, se consigue ocultar la
ubicación real de ese servidor central e impidiendo cualquier posible
acción de bloqueo de su contenido.

Migmaf es un curioso troyano cuya presencia puede pasar totalmente
inadvertida en los ordenadores infectados ya que no realiza ninguna
acción que revele su existencia. Únicamente una comprobación de los
servicios TCP/IP presentes en la máquina puede revelar su existencia,
ya que el troyano no realiza ningún acción hostil en el sistema donde
está instalado: únicamente utiliza su ancho de banda.

El funcionamiento del sistema es relativamente complejo. Las personas
que controlan la red disponen de una serie de dominios y asocia la
dirección IP de la máquina donde se está ejecutando el troyano con un
nombre de sistema dentro de esos dominios. Esto les permite tener
asociadas a los nombres utilizados en las URL virtualmente miles de
direcciones IP diferentes, en redes diversas y potencialmente
distribuidos por todo el planeta.

Cada vez que un ordenador infectado recibe una conexión al puerto
80/tcp (tráfico HTTP), redirecciona esta petición contra el servidor
máster. Una vez recibida la respuesta de ese máster, la envía al
ordenador que ha realizado la petición. De esta forma, los usuarios
que acceden a las páginas web no saben en ningún momento cual es el
sistema que realmente les está sirviendo el contenido. Para ellos es
el ordenador donde está el troyano. La existencia de varios millares
de sistemas con el troyano hace que cualquier intento de bloquear el
acceso al contenido del servidor central sea muy difícil.

Adicionalmente, el troyano está escuchando el puerto 81/tcp donde hay
un servidor socks de forma que desde el servidor central se puede
utilizar esta conexión para, por ejemplo, enviar correo spam de forma
que su origen queda totalmente oculto. Una vez más, los receptores del
spam consideran que es el sistema víctima quien ha realizado el envío.

Migmaf dispone de algunas funciones pensadas para hacer un uso
eficiente de los recursos. Así, por ejemplo, monitoriza el tiempo
utilizado para la transmisión de las páginas, enviando esta
información al servidor central. También envía unos cuantos centenares
de KB a www.microsoft.com para medir así cual es el ancho de banda
efectivo que dispone el sistema donde está instalado.

El troyano debe ser instalado manualmente en el ordenador víctima ya
que no dispone de ningún mecanismo de distribución conocido. La
existencia de un buen número de usuarios de AOL infectados sugiere la
posibilidad que se distribuya de alguna forma utilizando el sistema de
mensajería instantánea de este ISP.

En el momento de iniciar su ejecución comprueba si el sistema está
configurado con un teclado ruso y, en caso afirmativo, finaliza su
ejecución.

Detección y eliminación

Para detectar la presencia de Migmaf en un sistema puede determinarse
por la presencia del archivo %WINDIR%\SYSTEM32\WINGATE.EXE La
eliminación puede realizarse manualmente, editando el registro y
eliminando la entrada

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
Login Service = wingate.exe

Una vez borrada esta entrada, debe reiniciarse la máquina y borrar el
archivo %WINDIR%\SYSTEM32\WINGATE.EXE


Xavier Caballé
xavi@hispasec.com


Más información:

Backdoor.Migmaf
http://www.symantec.com/avcenter/venc/data/backdoor.migmaf.html

Proxy-Migmaf
http://vil.mcafee.com/dispVirus.asp?virus_k=100480

Migmaf
http://www.alertaantivirus.es/virus/detalle_virus.html?cod=2776

TROJ_MIGMAF.A
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=TROJ_MIGMAF.A

TROJ/MIGMAF-A
http://esp.sophos.com/virusinfo/analyses/trojmigmafa.html

Win32.Migmaf.A
http://www3.ca.com/virusinfo/virus.aspx?ID=35814

Hackers Hijack PC's for Sex Sites
http://news.com.com/2100-12_3-1024967.html

New Trojan turns home PCs into porno Web sites hosts
http://lists.netsys.com/pipermail/full-disclosure/2003-July/011139.html

Reverse-Proxy Spam Trojan: Migmaf
http://www.lurhq.com/migmaf.html

lunes, 14 de julio de 2003

Respuesta de Symantec al problema de seguridad en su servicio

En relación a la noticia "Symantec abre un agujero de seguridad en los
PCs", publicada el mes pasado en una-al-dia, Symantec nos ha hecho
llegar una nota que a continuación reproducimos íntegramente, en la
que se confirma la existencia de la vulnerabilidad y su corrección.

>>>

La vulnerabilidad descubierta en Symantec Security Check está ya
solucionada


Desde el descubrimiento de la explotación, Symantec ha trabajado
diligentemente para sustituir el ActiveX Control en Symantec Security
Check. A través de su soporte al cliente, Symantec está trabajando con
los usuarios que pueden haberse descargado ActiveX Control para
eliminarlo de sus sistemas. Aunque Symantec Security Check está
disponible tanto para usuarios de PC como de Mac, este asunto solo
afecta a los PCs.

Garantizar la protección y seguridad online de los consumidores es muy
importante para Symantec. Una vez que se comenzó a hablar de la
vulnerabilidad, rápidamente se ha informado a los usuarios de la
vulnerabilidad mediante consejos tanto en la página web de Symantec
Security Response como el BugTraq de Security Focus.

Symantec también ha creado una herramienta de limpieza para eliminar
ActiveX Control. Los usuarios que deseen descargarse la herramienta
pueden acceder a la dirección;

http://www.sarc.com/avcenetr/security/Content/2003.06.25a.html

Adicionalmente, a Symantec le gustaría aprovechar esta oportunidad
para educar a los consumidores sobre la importancia de incorporar las
mejores prácticas en todas las actividades que se lleven a cabo en
Internet para mantener los niveles más altos de protección y
seguridad. Symantec quiere alertar a los consumidores de que existe
la posibilidad que este ActiveX Control vulnerable sea utilizado por
otras personas para llevar a cabo actividades maliciosas. Por
consiguiente los consumidores, mientras navegan por la web, deberían
rechazar cualquier descarga de Active X que esté firmada por
Symantec, a menos que proceda de un dominio de Symantec.

<<<


Bernardo Quintero
bernardo@hispasec.com


Más información:

23/06/2003 - Symantec abre un agujero de seguridad en los PCs
http://www.hispasec.com/unaaldia/1702

Descarga de la Herramienta de Limpieza de Symantec
http://www.sarc.com/avcenter/security/Content/2003.06.25a.html

domingo, 13 de julio de 2003

Desbordamiento de búfer en convertidor HTML de Windows

Existe un fallo en la forma en que el convertidor HTML para Windows
trata una petición de conversión durante una operación de copiar y
pegar. Una petición especialmente creada al convertidor HTML puede
provocar el fallo de la utilidad, de forma que puede llegar a
producirse la ejecución de código en el contexto de seguridad del
usuario conectado.

Todas las versiones de Microsoft Windows contienen el soporte para convertir archivos incluido en el sistema operativo. Esta funcionalidad permite a los usuarios de Windows convertir desde un formato de archivo a otro. En particular, Microsoft incluye el soporte para convertir HTML dentro de sus sistemas operativos, a través de esta funcionalidad los usuarios pueden visualizar, importar, o grabar archivos como HTML.

Como esta funcionalidad se usa por Internet Explorer un atacante podrá
crear una página web maliciosa o un e-mail html malicioso de forma que
provoque que el convertidor HTML ejecute código arbitrario en el sistema
del usuario. Un usuario que visualice el sitio web creado por el
atacante podrá verse afectado sin necesidad de realizar ninguna
acción.

Las actualizaciones publicadas pueden descargarse desde las siguientes
localizaciones:
Windows NT 4.0 Server
http://microsoft.com/downloads/details.aspx?FamilyId=8849D376-D7C1-4040-BC83-FEA67AE57F5F&displaylang=en
Windows NT 4.0 Terminal Server Edition
http://microsoft.com/downloads/details.aspx?FamilyId=A64F5EEF-A3F5-466C-94D0-5EBF6231A612&displaylang=en
Windows 2000
http://microsoft.com/downloads/details.aspx?FamilyId=FF84E1A5-C90D-40F2-8CF5-23DA3AB296B4&displaylang=en
Windows XP 32 bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=11CDD153-65EC-4851-886C-5A412438D6D4&displaylang=en
Windows XP 64 bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=EE42EDF4-DEB2-450D-9F1A-90E41E908ECB&displaylang=en
Windows Server 2003 32 bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=1C9914AB-25F8-462E-ADC0-5AC6BD0116DE&displaylang=en
Windows Server 2003 64 bit Edition
http://microsoft.com/downloads/details.aspx?FamilyId=F9697DE0-488D-4CBA-996B-7ACEC50992CE&displaylang=en



Antonio Ropero
antonior@hispasec.com


Más información:

Buffer Overrun In HTML Converter Could Allow Code Execution (823559)
http://www.microsoft.com/technet/security/bulletin/ms03-023.asp

MS03-023: Buffer Overrun in the HTML Converter Could Allow Code Execution
http://support.microsoft.com/default.aspx?scid=kb;en-us;823559

What You Should Know About Microsoft Security Bulletin MS03-023
http://www.microsoft.com/security/security_bulletins/ms03-023.asp

sábado, 12 de julio de 2003

Actualización de seguridad de Apache 2.0.*

La fundación Apache acaba de publicar la versión 2.0.47 de su servidor,
que soluciona varios problemas de seguridad importantes.

Apache es el servidor web más popular del mundo, disponible en código
fuente y para infinidad de plataformas, incluyendo UNIX, Microsoft
Windows, OS/2 y Novell NetWare.

Además de solucionar numerosos bugs, los problemas de seguridad
eliminados son:

* Cuando en un directorio se configura un criptosistema más "fuerte" que
el configurado por defecto, bajo ciertas secuencias de renegociación y
dependiendo de la configuración del servidor, es posible que se
seleccione incorrectamente el criptosistema más "débil".

* Debido a un bug en "prefork MPM" (uno de los modelos de trabajo de
Apache), es posible crear una situación de denegación de servicio
temporal provocando ciertos errores en la llamada al sistema "accept()".

* Ataque de denegación de servicio en el módulo de proxy FTP, si el
destino es IPv6 y el módulo es incapaz de crear el "socket".

* Posibilidad de ataque DoS (Denegación de Servicio) debido a un bucle
infinito por redirecciones internas y subpeticiones anidadas.

Se recomienda a todos los usuarios de Apache 2.0.* que actualicen a la
versión 2.0.47. Estos problemas de seguridad no afectan a la serie 1.3.*
del servidor.


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


Más información:

Apache 2.0.47 Released
http://www.apache.org/dist/httpd/Announcement2.html

Apache 2 before 2.0.47, when running on an IPv6 host, allows attackers
to cause a denial of service when the FTP proxy server fails to create
an IPv6 socket.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0254

The prefork MPM in Apache 2 before 2.0.47 does not properly handle
certain errors from accept, which could lead to a denial of service.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0253

Apache 2 before 2.0.47, and certain versions of mod_ssl for Apache 1.3,
do not properly handle "certain sequences of per-directory
renegotiations and the SSLCipherSuite directive being used to upgrade
from a weak ciphersuite to a strong one," which could cause Apache to
use the weak ciphersuite.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0192

viernes, 11 de julio de 2003

La APD española advierte de un intento de fraude

La Agencia de Protección de Datos ha emitido una nota de prensa en la
que comunica la usurpación de su nombre con la finalidad de recabar
información de terceros.

Esta información solicitado hipotéticamente con el fin de proceder al
registro de los ficheros "no registrados" consistiría en los datos de
las cuentas bancarias de las empresas afectadas.

Cada vez suele ser mas habitual el pasar recibos bancarios a empresas
dando por hecho la solicitud de un servicio. Desde Hispasec Sistemas
aconsejamos en primer lugar dar orden de devolución del recibo en
cuestión seguido de la pertinente denuncia ante el juzgado. Es delicado
el que datos bancarios estén a disposición de empresas poco éticas y
mucho peor el cruzarnos de manos ante ello. No debemos olvidar que este
tipo de fraudes no sólo se realizan en Internet también existe en la
empresa clásica.

Nota Informativa de la Agencia de Protección de Datos

ADVERTENCIA PÚBLICA

Se ha tenido conocimiento en este Organismo de que se están enviando por
correo electrónico a responsables de ficheros automatizados mensajes en
los que aparece como remitente la Agencia de Protección de Datos -
Subdirección General de Inspección
(Inspeccion@agenciaprotecciondatos.org) y que, en síntesis, vienen a
indicar lo siguiente:

- "Habiendo recibido denuncias acerca de sus actividades en Internet por
estar usando direcciones de correo electrónico privadas que no están en
ninguna de las bases de datos que aquí se encuentran, procedemos a
instruirle un procedimiento sancionador", recordándole que el uso de
datos de carácter personal "puede suponer una multa de hasta 60.000
euros".

A la vista de lo anterior y sin perjuicio de las actuaciones legales que
esta Agencia de Protección de Datos pueda llevar a efecto, se informa de
que:

1.- Ninguno de los mensajes remitidos por correo electrónico procede de
esta Agencia de Protección de Datos.

2.- Las direcciones de correo electrónico privadas no quedan registradas
en las Bases de Datos de este Organismo.

3.- La actividad inspectora no se efectúa por correo electrónico, sino
mediante visita presencial debidamente autorizada, sellada y firmada por
el Director de la Agencia de Protección de Datos o comunicación por
correo ordinario en papel oficial de este Organismo.

4.- Las actuaciones que inician un procedimiento sancionador no se
comunican por correo electrónico, sino mediante Acuerdo oficial, firmado
por el Director de este Organismo, en el que se especifican las causas
de la supuesta infracción cometida y su fundamentación jurídica, dando
un plazo suficiente para presentar pruebas y alegaciones.

También se ha conocido por denuncias presentadas ante este Ente por
diferentes empresas, que han recibido llamadas telefónicas de quienes,
haciéndose pasar por la Agencia de Protección de Datos, les solicitan
los datos de su cuenta bancaria a efectos de pasarles los gastos por el
registro de sus ficheros.

A estos efectos se informa que:

1.- Ninguna llamada como las indicadas proviene de la Agencia de
Protección de Datos.

2.- La inscripción de ficheros en el Registro General de Protección de
Datos no devenga tasa ni precio público alguno.


Antonio Román
roman@hispasec.com


Más información:

Aviso Agencia de Protección de Datos
https://www.agenciaprotecciondatos.org/advertencia.htm

jueves, 10 de julio de 2003

Vulnerabilidad XSS en OWA permite obtener las credenciales del usuario

Descubierta una vulnerabilidad en OWA (Outlook Web Access) que puede
ser utilizada por un atacante remoto para obtener las credenciales del
usuario que abre un mensaje y hace clic en un enlace de dicho mensaje.

OWA, "Outlook Web Access" es un componente integral de Microsoft
Exchange que permite a los usuarios el acceso a su buzón de correo a
través de la web, utilizando cualquier sistema que ofrezca conexión a
la red. Es muy frecuente que aquellas organizaciones que utilizan
Exchange para el correo electrónico permitan a sus empleados utilizar
OWA como método para el acceso remoto al correo electrónico.

Al igual que Exchange, para acceder al buzón de correo mediante OWA es
preciso que previamente el usuario se autentique en el dominio.
Habitualmente se utiliza el dominio corporativo de la empresa, por lo
que la cuenta para el acceso al correo es la misma utilizada para la
identificación y acceso a los otros recursos de la red.

Un grupo de investigadores especializados en la seguridad de las
aplicaciones acaba de publicar la existencia de una vulnerabilidad del
tipo XSS (Cross Site Scripting) en OWA. Esta vulnerabilidad puede ser
empleada por un atacante remoto para conseguir las credenciales
utilizadas por el usuario para la autenticación. Con esta información,
el atacante podrá acceder al contenido del buzón de la víctima o, si
dispone de la posibilidad de conexión, suplantar su identidad dentro
de la red corporativa.

En teoría OWA realiza un filtrado de los mensajes que recibe para
evitar la presencia de código malicioso que pueda comprometer la
seguridad del navegador utilizado para la visualización de los
mensajes. No obstante, esta protección puede ser fácilmente
desactivada simplemente modificando el contenido de un parámetro que
se envía a través de la URL. Modificando este parámetro, OWA no aplica
ningún tipo de filtro a los mensajes que visualiza.

Esto puede ser utilizado por un atacante remoto para enviar a la
víctima un mensaje HTML conteniendo un enlace especialmente
codificado. Si la víctima hace clic sobre este enlace, se ejecuta el
código asociado al mensaje.

Hasta aquí nos encontramos con un típico problema de XSS. Lo destacado
de este caso es que esta vulnerabilidad permite aprovecharse del débil
mecanismo de seguridad utilizado por OWA para la protección de las
credenciales del usuario.

OWA, al igual que otros sistemas de mensajería, utiliza una cookie con
la información necesaria para evitar que un usuario ya autenticado
tenga que volver a introducir sus credenciales en cada operación.
Desgraciadamente, OWA utiliza un método muy débil para 'enmascarar'
las credenciales del usuario: simplemente las codificada en base64.

Cuando se definió el mecanismo de codificación base64 (RFC 1341 y
actualizado en el RFC 2045) se deseaba obtener un mecanismo simple
para la representación de datos de forma que no fueran directamente
legibles por los usuarios. No obstante, se trata de un mecanismo muy
simple y fácilmente reversible por lo que no debería utilizarse nunca
para ocultar información sensible, como son las credenciales del
usuario para el correo.

En el momento de redactar este boletín, Microsoft no ha publicado
todavía ninguna actualización de OWA que evite esta vulnerabilidad.
Hasta la disponibilidad de la misma, aconsejamos a los administradores
de sistemas de correo Exchange donde se utilice OWA que instruyan a
sus usuarios acerca de este problema y les pidan que extremen las
precauciones ante los mensajes que reciban con enlaces. La experiencia
dice que esto no sirve para evitar los problemas, pero poco más se
puede hacer.


Xavier Caballé
xavi@hispasec.com


Más información:

Microsoft User Domain Credentials access via OWA XSS
http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/OWA/OWA_XSS.htm

XSS in OWA allows stealing windows domain user credentials
http://www.securityfocus.com/archive/1/328105/2003-06-29/2003-07-05/1

Domain User Credentials access via OWA XSS
http://www.securityfocus.com/archive/1/328364/2003-07-06/2003-07-12/1

miércoles, 9 de julio de 2003

Continúan los intentos de fraude a través de correos masivos

Recientemente informábamos de un intento de fraude a los clientes del
BBVA, en Hispasec hemos podido comprobar que estos ataques se están
reproduciendo entre usuarios de otros servicios, como PayPal.

El intento de fraude se basa en el envío masivo (utilizando técnicas
de spam) de un mensaje simulando una comunicación de PayPal a sus
usuarios, en el que se les insta a que confirmen su cuenta de usuario
a fin de detectar usuarios inactivos y buzones no funcionales.

PayPal es un sistema basado en cuentas de usuario, que permite que
cualquiera con una dirección de correo electrónico enviar de forma
segura y recepcionar pagos de forma online empleando su tarjeta de
crédito o cuenta bancaria.

Al menos hemos detectado dos formas diferentes de intento de obtención
de los datos de los usuarios. En uno de los mensajes el formulario de
toma de datos iba incluido en el propio mensaje, mientras que en
segundo se instaba a los usuarios a visitar una página falsificada de
la forma http://www.paypal.com/@211.229.208.136/pp/processing.htm.

En todos los casos, los mensajes están perfectamente construidos,
empleando los propios logos de PayPal y mensajes de notificaciones,
copyright, etc. haciendo referencia a la empresa. El fraude está
dirigido a obtener los datos personales de usuarios, incluyendo su
nombre completo, dirección de correo, contraseña, y datos de la
tarjeta de crédito.

El problema no parece único, Sony Electronics ha anunciado la
existencia de un correo electrónico falso y no autorizado que hace uso
de su nombre para conseguir información de los usuarios. Un correo
enviado de forma masiva bajo el asunto de "Sonystyle user and email
address." solicita información personal de los usuarios. En una
nota de prensa publicada en http://news.sel.sony.com/pressrelease/3817
la compañía deniega toda implicación en estos correos.

Para evitar caer en este tipo de fraudes la propia PayPal ofrece en
http://www.paypal.com/cgi-bin/webscr?cmd=p/gen/fraud-prevention-outside
algunos consejos y medidas de seguridad. Entre ellos se recomienda
no compartir la contraseña con ningún sitio, ni ofrecer datos
bancarios, ni información sensible sobre nuestra identidad en ningún
sitio que no nos ofrezca las debidas condiciones de garantía, así como
comprobar la existencia de certificados de seguridad cuando se
solicitan este tipo de datos.

Desde Hispasec Sistemas recomendamos a nuestros lectores que siempre
desconfíen de este tipo de peticiones que una compañía jamás haría a
sus clientes. Deben de prestar especial cuidado en no introducir datos
(relativos a información bancaria y contraseñas) en formularios
recibidos por e-mail y en sitios cuya autoría sea dudosa o no esté
contrastada, así como verificar la existencia de los correspondientes
certificados de seguridad.



Antonio Ropero
antonior@hispasec.com


Más información:

una-al-dia (20/05/2003) Intento de fraude a los clientes del BBVA
http://www.hispasec.com/unaaldia/1668/comentar

SONY ALERTS CONSUMERS OF FRAUDULENT SPAM E-MAIL
http://news.sel.sony.com/pressrelease/3817

PayPal. Security Tips
http://www.paypal.com/cgi-bin/webscr?cmd=p/gen/fraud-prevention-outside

martes, 8 de julio de 2003

Vieja vulnerabilidad reaparece en Internet Explorer

Internet Explorer se bloquea si introducimos como dirección la
cadena C:\AUX o visualizamos una página web que contenga etiquetas
HTML con referencias a dicho nombre de archivo, lo que posibilita
realizar ataques DoS de forma remota. Una vez más las actualizaciones
de Microsoft reintroducen en los sistemas viejas vulnerabilidades
conocidas y corregidas en su día.

Los bloqueos y cuelgues en Windows ocasionados por hacer referencias a
archivos con nombres de dispositivos DOS, como CON, AUX, LPT1, COM1,
etc., fueron ya comentados en "una-al-dia" de Hispasec a principios de
marzo de 2000. En ese mismo aviso se hacía referencia también a las
posibilidades de llevar a cabo ataques DoS (denegación de servicios)
a través de páginas web con etiquetas que hicieran referencias a
estos nombres de archivos, exactamente el mismo escenario que tres
años más tardes nos volvemos a encontrar.

Microsoft publicó el correspondiente parche a mediados de marzo de
2000, quedando corregida la vulnerabilidad. Estos últimos días se ha
comprobado que, de nuevo, es posible provocar el DoS en Internet
Explorer haciendo referencia a C:\AUX. En estos momentos en los foros
de seguridad informática se está intentando acotar en que versiones de
Internet Explorer, y a partir de que parche, se puede reproducir el
problema. Si bien pruebas realizadas en diversos sistemas, incluyendo
Windows 2000 y Windows XP con las últimas actualizaciones y versión
de Internet Explorer instaladas, han resultado afectadas.

Para comprobar si nuestro Internet Explorer está afectado basta con
que introduzcamos C:\AUX en la barra de direcciones y pulsemos intro.
Si la ventana de Internet Explorer se queda bloqueada, nuestro sistema
ha "heredado" la vulnerabilidad a través de alguna actualización de
Microsoft.

Para provocar este mismo efecto de forma remota basta con construir
una página web con etiquetas que hagan referencia a este nombre de
archivo, por ejemplo un simple . Si un usuario intenta
visualizar la página web su sesión de Internet Explorer quedará
colgada. Este mismo ataque podría llevarse a cabo a través de e-mail,
enviando un mensaje con formato HTML que incluya la mencionada
etiqueta.

La vulnerabilidad no puede considerarse crítica, más bien un incordio,
lo único que provoca es el bloqueo de la ventana de Internet Explorer.
Para cerrarla podemos acudir al administrador de tareas, pestaña
aplicaciones, y finalizar la tarea que no responde.

De momento no hay solución disponible, a la espera de que Microsoft
distribuya un nuevo parche para corregir la vulnerabilidad, y confiar
en que el mismo no reintroduzca otros problemas.

Las regresiones de vulnerabilidades en Microsoft no son nuevas, y
aunque este caso concreto puede considerarse anecdótico, en otras
ocasiones tiene implicaciones críticas en materia de seguridad.
Recomiendo la lectura adicional de las noticias que aparecen en el
apartado "Más información" para conocer como esta problemática
afecta a nuestros sistemas.


Bernardo Quintero
bernardo@hispasec.com


Más información:

30/12/2002 - Actualizaciones de Microsoft, un arma de doble filo
http://www.hispasec.com/unaaldia/1527

11/11/2002 - Certificaciones de productos, ¿garantía de seguridad o
marketing?
http://www.hispasec.com/unaaldia/1478

19/02/2002 - Microsoft STPP, ¿estrategia tecnológica o lavado de cara?
http://www.hispasec.com/unaaldia/1213

13/06/2001 - Tercera revisión de un parche de Microsoft
http://www.hispasec.com/unaaldia/962

lunes, 7 de julio de 2003

Denegación de servicio remota en el cliente Trillian

Se ha anunciado la existencia de una vulnerabilidad de denegación de
servicio explotable de forma remota en el cliente de chat Trillian.

El cliente Trillian es una aplicación gratuita, sin ningún tipo de
limitación, ni spyware ni publicidad, que permite la conexión al IRC y
a redes de mensajería instantánea como ICQ, AIM, MSN Messenger y
Yahoo! Messenger, todo desde un único interfaz. Según informa la
propia web del producto ya cuenta con más de ocho millones de
descargas.

Es posible provocar la caída de Trillian mediante el envío de un
mensaje 'TypingUser' modificado. Mediante la sustitución de cualquiera
de los caracteres de 'TypingUser' se producirá la denegación de
servicio, salvo si se usan más de diez caracteres o si se omiten los
dos puntos. El problema se debe a una función de la librería msn.dll
tanto para Trillian 1 como para la versión 0.74.

Para explotar esta vulnerabilidad no es necesario ningún código
especial, basta con editar en hexadecimal el cliente reemplazando la
cadena 'TypingUser' con cualquier otra cadena de la misma longitud.
Hay que tener presente que esta forma de explotar la vulnerabilidad
rompe todos los acuerdos de licencia por lo que no se recomienda su
utilización.


Antonio Ropero
antonior@hispasec.com


Más información:

Cerulean Studios Trillian Client Malformed TypingUser Denial Of Service Vulnerability
http://www.securityfocus.com/bid/8107/info/

Trillian Remote DoS
http://www.securityfocus.com/archive/1/327940

Trillian (Cerulean Studios)
http://www.trillian.cc

domingo, 6 de julio de 2003

Ninguna repercusión real del concurso de ataques a sitios web

Pese a todo el revuelo y sensacionalismo mediático montado alrededor
del concurso de desfiguración a sitios web, la jornada en la que se
suponía habría importantes ataques está finalizando sin apenas
incidencias. Lo más relevante ha sido el ataque DDoS que desde la
propia comunidad underground se ha lanzado al sitio donde los
participantes al concurso debían de registrar los ataques perpetrados.

A primera hora de la mañana de hoy domingo ya pudimos comprobar desde
Hispasec que el dominio de la página web que anunciaba el concurso
se encontraba de nuevo en línea, después de que el ISP donde
anteriormente estaba hospedada la eliminara. En esta ocasión se ha
alojado en un sitio gratuito brasileño. En la página, el promotor del
concurso daba el pistoletazo de salida y ampliaba el plazo de 6 horas
a 24, de forma que finalizaba la madrugada del domingo a las 00:00,
ya 7 de julio.

La razón que se daba a esta ampliación es que el sitio elegido para
que los participantes pudieran registrar sus ataques estaba
inaccesible. Comprobamos que efectivamente el web no respondía, la
duda era si el colapso se debía a tráfico legítimo generado por el
gran número de visitantes que pretendían ver la marcha del concurso,
o si el motivo respondía además a algún tipo de ataque DoS
(denegación de servicio).

Más tarde se publicaría en diversos sitios un comunicado firmado por
varios integrantes de grupos undergrounds que reclamaban la autoría
de un ataque DDoS a Zone-h, el sitio web que debía registrar los
ataques y serviría de contador para montar el ranking. La
justificación de este ataque, según el comunicado, es una protesta
al sensacionalismo con que los medios de comunicación habían tratado
este caso, la exageración, y la prostitución que hacen del término
"hacker".

En un intento de salvar el concurso, el promotor del mismo y Zone-h,
el sitio web que debía hacer las veces de ranking en línea,
publicaron varias direcciones de e-mail y habilitaron otros sitios
desde donde los participantes podrían enviar los ataques perpetrados.
Pese a esta salida, alrededor de las 20:00h de la tarde el
administrador de Zone-h daba como resultados unos 450 "defacements"
(ataques y desfiguraciones a sitios webs). Una cifra ridícula, si
tenemos en cuenta que la media de ataques a sitios webs registrados
por la propia Zone-h en los domingos del mes pasado es de 581, con
picos como por ejemplo el alcanzado el domingo 22 de junio con 913
"defacements".

Aunque en las últimas horas esta cifra crezca, la realidad es que el
ataque no ha tenido ninguna repercusión en la red. Ningún sitio web
importante se ha visto afectado y, tal y como adelantamos en Hispasec
unos días antes, sólo los sistemas con vulnerabilidades conocidas y
fáciles de explotar han resultado dañados, como ocurre a diario.

Resumiendo, la organización, participación, y objetivos del concurso,
han resultado todo un fracaso. Las alertas y noticias que anunciaban
un ataque masivo, pueden considerarse un "hype" (exageración
informativa). En este paquete se encuentra desde el aviso del gobierno
USA, o alguna que otra empresa de seguridad que aprovechó la coyuntura
para ofertar auditorías web como medida de prevención ante el
inminente ataque.

Mención aparte merecen los medios de comunicación general. Aunque el
concurso en sí mismo no tenía credibilidad alguna (ni por la
organización, ni por los premios), la cobertura sensacionalista que
se le ha dado ha servido como altavoz, de forma que, en vez de llegar
a unos pocos cientos de posibles atacantes, el concurso ha tenido
publicidad gratuita alrededor de todo el mundo, con el agravante de
que ha fijado la atención de los medios (escaparate de lujo si algún
grupo cracker quería dar la nota). Este hecho era el que mantenía la
incertidumbre sobre el resultado final, dependiendo del poder de
convocatoria que finalmente reuniría, ya que técnicamente era
factible realizar los ataques que se proponían como reto.

Afortunadamente todo lo sucedido alrededor del concurso ha terminado
por generar un rechazo generalizado desde la comunidad underground.
Además del comentado ataque DDoS al sitio que debía registrar los
ataques, algunos sitios han realizado "autodefacements", modificando
sus propias portadas webs en señal de protesta y burla.


Bernardo Quintero
bernardo@hispasec.com


Más información:

03/07/2003 - Incertidumbre sobre posible ataque masivo el próximo domingo
http://www.hispasec.com/unaaldia/1712

sábado, 5 de julio de 2003

Guía de Microsoft para la gestión de parches

Microsoft publica una guía con información para ayudar a los
administradores en las tareas de administración y gestión de los
parches, en vistas a disponer de un entorno seguro.

En los últimos meses se ha repetido varias veces la misma historia: un
gusano o un virus, utilizando una vulnerabilidad de un producto de
Microsoft, ha conseguido una notable propagación, consiguiendo en
algunos casos incluso afectar al correcto funcionamiento de la red en
su globalidad. Nos referimos a los sucesos que en su día provocaron
Code Red, Nimda, Klez o el SQL Slammer y sobre los que ya hemos
dedicado varias ediciones de el "una-al-día" de Hispasec.

Todos estos incidentes han tenido un aspecto clave en común: se
aprovechaban de vulnerabilidades para las cuales hacía meses que se
había publicado su correspondiente parche. Estos incidentes pusieron
de relieve la gran cantidad de sistemas existentes sobre los cuales no
se aplican las actualizaciones de seguridad (en muchos seguramente se
aplicaba aquella vieja máxima informática de "si funciona, no lo
toques"; en muchos más seguramente había una clara negligencia
profesional por parte de sus administradores).

No obstante, el problema no era tan simple. Tal como indicó mi
compañero Bernardo Quintero, la nueva estrategia utilizada por
Microsoft para la distribución de parches no era bien vista por los
administradores de redes, debido a su elevado nivel de abstracción y
al poco control que se tenía sobre la aplicación de los parches.

Esta política oscura ha provocado en diversas ocasiones problemas de
regresión. Es decir, que al aplicar un parche posterior,
vulnerabilidades previamente solucionadas vuelven a estar presente en
los sistemas.

Con el claro objetivo en quitarse este sanbenito de encima, Microsoft
acaba de publicar una completa "Guía para la gestión de parches" que
tiene como objeto mostrar a los administradores de redes que trabajan
con productos de Microsoft cuales son las diversas opciones existentes
para el despliegue, en el ámbito global de la red, los diferentes
parches que se van publicando. De esta forma, no sólo se aplican
medidas reactivas (instalación de un parche), sino que éstas acaban
convirtiéndose en medidas preventivas que evitan posibles incidencias
como las provocadas por los virus y gusanos anteriormente citados.

La guía, que se puede descargar desde http://go.microsoft.com/fwlink/?LinkId=16286
se compone de un manual, en formato PDF, y de un conjunto de
herramientas y plantillas que pueden ser utilizados por los
administradores para la aplicación de los parches en el ámbito de una
red.

El manual se divide en dos partes. La primera es una introducción a la
administración de parches e introduce al lector en los conceptos
necesarios para poder preparar su entorno. La segunda parte, la más
interesante, trata del ciclo de vida de la gestión de parches.

Entre las herramientas, disponemos de diversos scripts para la
obtención de información en los sistemas, así como la aplicación de
parches utilizando el Microsoft SMS.


Xavier Caballé
xavi@hispasec.com


Más información:

Microsoft Guide to Security Patch Management
http://go.microsoft.com/fwlink/?LinkId=16284

Descarga de la Microsoft Guide to Security Patch Management
http://go.microsoft.com/fwlink/?LinkId=16286

una-al-día (27-01-03): Lecciones del gusano MS-SQL
http://www.hispasec.com/unaaldia/1555

una-al-día (26-01-03): Alerta: Gusano para MS-SQL
http://www.hispasec.com/unaaldia/1554

La propaganda sobra la ciberguerra no evita que Internet sea un "gruyère"
http://ww2.grn.es/merce/2003/gruyere.html

una-al-día (30-12-02): Actualizaciones de Microsoft, un arma de doble filo
http://www.hispasec.com/unaaldia/1527

una-al-día (29-07-02): Parche del parche para Windows Media Placer
http://www.hispasec.com/unaaldia/1373

una-al-día (19-02-02): Microsoft STTP, ¿estrategia tecnológica o lavado de cara?
http://www.hispasec.com/unaaldia/1213

una-a-día (18-02-02): Microsoft lanza en España su iniciativa STTP
http://www.hispasec.com/unaaldia/1212

viernes, 4 de julio de 2003

El 68% de las empresas españolas tienen una seguridad deficiente

Un reciente estudio asegura que el 68% de las grandes empresas
Españolas no están suficientemente protegidas frente ataques contra sus
sistemas informáticos. Dentro de este estudio realizado por HP el
sector financiero es el que sale mejor parado ante potenciales ataques
informáticos.

El estudio ha cubierto un amplio abanico de sectores críticos, como
las grandes corporaciones o la administración pública. Concretando un
poco más, los números pueden dar un poco de claridad ante el panorama
de la seguridad empresarial española. Los sectores analizados son el
financiero (23%), telecomunicaciones (36%), industria (26%) y el sector
público con un 15%.

Únicamente un 13% de las empresas estudiadas presenta unos niveles de
protección altos, seguidas por un 19% con un nivel medio de seguridad,
al igual que un 68% con niveles de protección bajos. Los números nos
hacen ver una realidad bastante preocupante, ya que una visión más
detenida nos hará ver este estudio como algo que nos afecta a todos
nosotros como usuarios o clientes. Son nuestro datos personales,
nuestra información sensible, la que se encuentra en estas empresas
estudiadas.

Las entidades financieras son las que mejor paradas salen, quedando a
muy bajo nivel las instituciones públicas estudiadas. ¿Es esto lógico?
¿no deberían ser las instituciones, las encargadas de velar de nuestros
datos con un mayor celo?.

Según el propio informe, "en general, se puede afirmar que el sector
financiero es el que más concienciación tiene sobre la seguridad
informática. Las empresas de este sector son conscientes de la
repercusión negativa que tendría para su propio negocio un ataque a
sus sistemas con información confidencial."

Durante el estudio realizado por HP, del total de compañías analizadas
únicamente un 5% detectó las intrusiones realizadas por el equipo
encargado del estudio frente a un 95% que no fue capaz de detectar que
sus sistemas estaban siendo atacados. Este dato, según piensan los
técnicos encargados del estudio "es bastante relevante y pone de
manifiesto que un porcentaje importante de los ataques que están
ocurriendo hoy día pasan totalmente desapercibidos". Apreciación que
comparto completamente.


Antonio Román
roman@hispasec.com


Más información:

Un Estudio de Seguridad de HP asegura que el 68% de las grandes
corporaciones no están lo suficientemente protegidas contra ataques
en sus sistemas.
http://www.hp.es/noticias/julio2003/noticia05.htm