El año de las "grandes catástrofes" en Internet

Si por algo se ha caracterizado (y se recordará) 2008 es por convertirse
en el año de las grandes catástrofes en Internet, con el descubrimiento
de hasta cinco graves vulnerabilidades que hacían tambalearse los
cimientos de la Red. En contraste, durante el año, la mayoría de los
atacantes han seguido valiéndose sobre todo de fallos "tradicionales".

El "despiste" de Debian

En mayo se descubre que el generador de números aleatorios del paquete
OpenSSL de Debian es predecible. Esto hace que las claves generadas con
él ya no sean realmente fiables o verdaderamente seguras. Alguien (por
error) del equipo de Debian eliminó en 2006 una línea de código en el
paquete OpenSSL de Debian que ayudaba a generar la entropía al calcular
el par de claves pública y privada.

Kaminsky y los DNS

El 8 de julio de 2008 se publica una actualización coordinada para
la mayoría de los dispositivos en Internet que utilizan DNS. Ha sido
descubierta una vulnerabilidad inherente al protocolo que permite
falsificar las respuestas DNS y, por tanto, redireccionar el tráfico.
Cisco, Microsoft, BIND... todos publican una nueva versión o actualizan
sus sistemas para solucionar un misterioso fallo. Dan Kaminsky es el
responsable de orquestar la macroactualización. Thomas Dullien se
aventura semanas después a publicar en su blog su particular visión
de lo que podía ser el problema descubierto por Kaminsky, sin tener
conocimiento previo de los detalles. Y no se equivoca en su teoría:
es posible falsificar (a través del envío continuo de cierto tráfico)
los servidores autorizados de un dominio.

Espionaje a "gran escala" con BGP

En agosto se habla de nuevo de la mayor vulnerabilidad conocida al
demostrar Tony Kapela y Alex Pilosov una nueva técnica (que se creía
teórica) que permite interceptar el tráfico de Internet a una escala
global. Se trata de nuevo de un fallo de diseño en el protocolo BGP
(Border Gateway Protocol) que permitiría interceptar e incluso modificar
todo el tráfico de Internet no cifrado. BGP es un protocolo que se
utiliza para intercambiar tablas de enrutamiento entre sistemas
autónomos (AS). El problema es que nunca se ha llegado a idear un
sistema que realmente autentique a ambas partes, y los routers estén así
seguros de que la información recibida desde un AS es legítima y viene
del sitio adecuado.

La denegación de servicio "perfecta"

Por cuarta vez en el año, se habla de la mayor vulnerabilidad encontrada
en la Red. La compañía sueca Outpost24 dice que descubrió en el 2005
(aunque lo saca a la luz 3 años después, posiblemente animada por los
otros acontecimiento) varias vulnerabilidades de base en el mismísimo
protocolo TCP/IP que podrían permitir la caída de cualquier aparato con
comunicación TC en la Red. Es la llamada "denegación de servicio de bajo
ancho de banda". Aunque todavía no se conocen los detalles, todo son
conjeturas. Dicen no conocer una implementación de la pila que no sea
vulnerable. La información sobre lo que se da en llamar Sockstress se
estanca. Finalmente no ofrecen los detalles prometidos aunque pueden
demostrar su eficacia.

¿El fin del WiFi?

A principios de octubre se publica que la compañía rusa ElcomSoft había
conseguido reducir sustancialmente el tiempo necesario para recuperar
una clave de WPA, ayudándose de tarjetas gráficas NVIDIA y fuerza bruta.
Se trata más de una maniobra de publicidad que una vulnerabilidad real.
Sin embargo poco después Tews y Beck encuentran un problema inherente a
una parte de WPA con el cifrado TKIP. Aunque la noticia es exagerada en
medios, realmente se trata de una prueba de concepto que no permite
recuperar la contraseña ni influye al método de autenticación. La
técnica está limitada a descifrar paquetes concretos o inyectar nuevos
(y sólo una pequeña cantidad) de tamaño reducido. Aun así parece el
principio del fin para WPA y un acicate para pasar a WPA2.

Problemas en IPv6

En julio también se descubrió un problema en todas las implementaciones
del protocolo Neighbor Discovery Protocol (NDP) para detectar nodos
IPv6. Un atacante podría interceptar tráfico privado. Todos los grandes
fabricantes deben actualizar.

Los ataques más usados

Aunque se han detectado ataques a servidores SSH que se sospecha estaban
relacionados con el problema de Debian y desde China se han observado
ataques contra la vulnerabilidad DNS descubierta por Kaminsky, del resto
de graves vulnerabilidades no se tiene constancia de que estén siendo
aprovechadas al menos de forma masiva.

En realidad, los ataques masivos del "día a día" que se han sufrido este
año han tenido su origen una vez más en vulnerabilidades "tradicionales"
que permiten ejecución de código en software popular. Las
vulnerabilidades que más han sido aprovechadas de forma masiva en 2008
(aunque no las únicas, sí las de mayor impacto) han sido:

* En enero, los atacantes aprovechan de forma masiva una vulnerabilidad
en RealPlayer.

* En febrero se descubre que un fallo en Adobe Acrobat/Reader 8 está
siendo aprovechado para infectar sistemas. También aprovecharían otra
vulnerabilidad para infectar a través de archivos PDF en noviembre .

* En abril, una vulnerabilidad de ejecución de código en el motor GDI
de Windows.

* En mayo, un problema en el reproductor Flash de Adobe.

* El día 23 de octubre Microsoft publica un parche fuera de su ciclo
habitual en el que se soluciona un fallo de seguridad en el servicio
Server. Es problema es muy parecido al que aprovechó Blaster en 2003.
No se convierte en epidemia pero es muy aprovechado en redes internas.

* La vulnerabilidad en el manejo de etiquetas XML de Internet Explorer.
El 17 de diciembre Microsoft publica otro parche fuera de su ciclo
porque la vulnerabilidad está siendo masivamente explotada.

Casi siempre, todas estas vulnerabilidades se aprovechan con el fin
de instalar malware y obtener así un lucro directo de los sistemas
atacados. 

Actualización del kernel para Debian Linux 4.x

Debian ha publicado una actualización del kernel que corrige múltiples
fallos de seguridad que podrían causar una denegación de servicio o una
elevación de privilegios.

Los problemas corregidos son:

* Denegación de servicio local o escalada de privilegios en
rch/i386/kernel/sysenter.c a través de las funciones
install_special_mapping, syscall y syscall32_nopage.

* Denegación de servicio local a través de los sistemas de archivos ext2
y ext3. Un usuario local con permisos para montar sistemas de archivos
podría crear un sistema de archivos especialmente manipulado pudiendo
hacer que el kernel envíe mensajes de error de forma indefinida.

* Salto de restricciones de seguridad a través de splice() en archivos
abiertos con O_APPEND, que podría permitir la escritura en dicho
archivo.

* Posibles denegaciones de servicio remoto a través del subsistema SCTP
(kernel oops y kernel panic).

* Denegaciones de servicio local a través del sistema de archivos
hfsplus. Un usuario local con permisos para montar sistemas de archivos
podría crear un sistema de archivos especialmente manipulado que podría
dar lugar a una corrupción de memoria o kernel oops.

* Denegación de servicio, a través del subsistema de sockets unix, que
podría causar una corrupción de memoria o kernel panic.

* Denegación de servicio, a través de la función svc_listen de
net/atm/proc.c. Un usuario local podría provocar un bucle infinito
mediante dos llamadas a svc_listen hacia el mismo socket y, a
continuación, una lectura del archivo /proc/net/atm/*em.

* Elevación de privilegios a través de inotify. Un usuario local podría
obtener una elevación de privilegios a través de vectores desconocidos
relacionados con condiciones de carrera en inotify y umount.

* Denegación de servicio a través de la función sendmsg y AF_UNIX. Un
usuario local mediante múltiples llamadas a la función sendmsg podría
causar una denegación de servicio debido a que AF_UNIX no bloquea estas
peticiones durante la recolección de basura y provoca una condición OOM.

Se recomienda actualizar a través de las herramientas automáticas
apt-get.

Ejecución de código a través de la extensión mbstring de PHP 5.x y 4.x

Se ha encontrado una vulnerabilidad en PHP, en la extensión de
tratamiento de cadenas con tipografía multibyte, que podría permitir
a un atacante ejecutar código arbitrario.

El fallo se debe a un desbordamiento de memoria basado en heap en la
extensión mbstring que podría permitir la ejecución de código con los
privilegios del servicio objetivo. El problema se da en el código que
decodifica cadenas que contienen entidades HTML a cadenas Unicode
(mbfilter_htmlent.c).

Las funciones afectadas (entre otras) son:
mb_convert_encoding()
mb_check_encoding()
mb_convert_variables()
mb_parse_str()

Son vulnerables todas las versiones anteriores a la 4.3.0 y 5.2.7. El
problema ha sido solucionado en la versión 5.2.8 disponible en
www.php.net 

La familia de malware DNSChanger instala "simuladores de DHCP" en la víctima

Hace unos días, tanto el SANS como distintas casas antivirus advertían 
de un comportamiento más que curioso en la vieja conocida familia de 
malware DNSChanger. Esta ha evolucionado sustancialmente: Comenzó con el 
cambio local de la configuración de servidores DNS en el sistema (para 
conducir a la víctima a los servidores que el atacante quiera). Ha 
llegado hasta el punto de instalar una especie de servidor DHCP e 
infectar así a toda una red interna. Los servidores DNS que instala 
el malware suelen estar en la red conocida como UkrTeleGroup. 
 
La familia DNSChanger 
 
Una característica interesante de DNSChanger es que es una de las 
familias que más han atacado a sistemas Mac, además de a Windows. Entre 
otras muchas formas de toparse con ellos, se suelen encontrar en 
servidores eMule, camuflados bajo la apariencia de otros programas. 
 
Es una familia conocida desde hace unos tres años. Se caracterizan por 
modificar los servidores DNS de la víctima a la que infectan. De esta 
forma, la asociación IP-Dominio queda bajo el control del atacante, de 
manera que la víctima irá a la IP que el atacante haya configurado en su 
servidor DNS particular. Normalmente, se confía en los DNS de los ISP, 
pero si se configura cualquier otro, realmente la resolución queda a 
merced de su administrador, cualesquiera que sean sus intenciones. 
 
DNSChanger comenzó modificando la configuración del sistema en local, de 
forma que cambiaba los servidores DNS del ISP de la víctima por otros 
controlados por el atacante. Después, el malware evolucionó hacia la 
modificación del router ADSL de la víctima. Buscaba la "puerta de 
enlace" del sistema, que suele corresponderse con el router, y realizaba 
peticiones o aprovechaba vulnerabilidades de routers conocidos para 
modificar estos valores. Así el usuario se veía afectado por el cambio 
pero de una forma mucho más compleja de detectar. Además, también se 
verían afectadas el resto de las máquinas que tomaran estos valores del 
propio router. 
 
Dando un paso más allá 
 
La última evolución observada implica la instalación en la víctima de un 
pequeño servidor DHCP. Este es el protocolo usado en las redes locales 
para que cuando un sistema se conecta a la red, el servidor lo reconozca 
y le proporcione de forma automática los valores necesarios para poder 
comunicarse (dirección, ip, puerta de enlace...). Habitualmente también 
proporciona los valores de los servidores DNS que haya establecido el 
administrador o el router. 
 
El malware instala un driver que le permite manipular tráfico Ethernet a 
bajo nivel, o sea, fabricar paquetes de cualquier tipo. Con esta técnica 
simula ser un servidor DHCP. Cuando detecta preguntas de protocolo DHCP 
legítimas de algún sistema en la red, el malware responde con su propia 
configuración de DNS, de forma que el ordenador que acaba de enchufarse 
a la red local, quedaría configurado como el atacante quiere, y no como 
el administrador ha programado. El atacante confía en la suerte, pues el 
servidor DHCP legítimo de la red, si lo hubiese, también respondería. 
Quien llegue antes "gana". Consiguen así infecciones "limpias", pues es 
complicado saber quién originó el tráfico si éste no es almacenado y 
analizado. Además, con este método se pueden permitir realizar muchos 
otros ataques en red local con diferentes impactos. 
 
¿Qué valores DNS introduce el malware? 
 
DNSChanger es una familia que necesita de una importante infraestructura 
para que sea útil. Los servidores DNS (bajo el control de los atacantes) 
de los que se vale, los que modifica en el usuario, suelen estar 
alojados en la compañía ucraniana UkrTeleGroup, bajo el rango de 
red 85.255.x.y. Casi un 10% de todas las máquinas en ese rango de 
direcciones se corresponden con servidores DNS públicos que no contienen 
las asociaciones legítimas de domino y dirección IP. En ocasiones 
utilizan el servidor DNS para asociar dominios a la IP reservada 
127.0.0.1, como es el caso del servidor de descargas de Microsoft 
download.microsoft.com. Con esto se consigue que la víctima no pueda 
actualizar el sistema operativo con parches de seguridad. Curiosamente, 
al parecer, las direcciones de actualización de Apple no están 
bloqueadas (a pesar de que suele afectar a este sistema operativo). 
También se bloquean un buen número de páginas de actualizaciones de 
casas antivirus. 
 
Algunos de estos servidores DNS (ATENCIÓN: no configurarlos en el 
sistema bajo ningún concepto) son: 
 
85.255.122.103, 85.255.113.114, 85.255.122.103, 85.255.112.112... 
 
Sólo son necesarias algunas consultas "dig" (comando para averiguar qué 
direcciones están relacionadas con qué dominios en un servidor DNS) para 
comprobar qué dominios "interesan" o no a los atacantes.


Rogue DHCP servers
http://isc.sans.org/diary.php?storyid=5434
 
DNSChanger: One Infection, Lots Of Problems
http://www.avertlabs.com/research/blog/index.php/2008/12/16/dnschanger-one-infection-lots-of-problems/
 

Escalada de privilegios en Microsoft SQL Server 2000 y 2005

Se ha encontrado una vulnerabilidad en Microsoft SQL Server 2000 y 2005
que podría ser explotada por un atacante de la red local para escalar
privilegios.

La vulnerabilidad está causada por un error de límites en la
implementación de "sp_replwritetovarbin()" que podría provocar un
desbordamiento de búfer basado en heap. Esto podría ser explotado por un
atacante remoto para escalar privilegios mediante el paso de argumentos
especialmente manipulados a la función.

La vulnerabilidad está confirmada para Microsoft SQL Server 2000 versión
8.00.2050 y existe un exploit público capaz de aprovechar esta
vulnerabilidad.

Se recomienda deshabilitar el procedimiento extendido
sp_replwritetovarbin con el comando:
dbo.sp_dropextendedproc 'sp_replwritetovarbin'


Microsoft SQL Server sp_replwritetovarbin limited memory overwrite vulnerability
http://www.sec-consult.com/files/20081209_mssql-2000-sp_replwritetovarbin_memwrite.txt

Ejecución de código arbitrario en CA ARCserve Backup

Se ha descubierto una vulnerabilidad en CA ARCserve Backup que podría
permitir a un atacante remoto causar una denegación de servicio o la
ejecución de código arbitrario.

CA ARCserve Backup es una suite de gestión de almacenamiento y
recuperación de datos muy usada en el mundo empresarial. Soporta las
diferentes plataformas integradas en la red, servidores bajo diferentes
dominios o soluciones virtualizadas bajo VMware. Ofrece gestión
centralizada de procesos, informes e integración de medidas antivirus y
de cifrado.

El fallo se debe a una insuficiente verificación de los datos del
cliente. Un atacante remoto podría provocar la caída del servicio
LDBserver o ejecutar código arbitrario en el contexto del servicio. Solo
afecta a la aplicación servidor bajo Windows.

CA ha asignado un alto riesgo a esta vulnerabilidad y ha publicado las
siguientes actualizaciones según versión:
CA ARCserve Backup r12.0 Windows: Instalar Service Pack 1 (RO01340)
CA ARCserve Backup r11.5 Windows: RO04383
CA ARCserve Backup r11.1 Windows: RO04382
CA Protection Suites r2: RO04383

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3704/comentar

Denegación de servicio a través de libICE en Solaris

Sun ha publicado una actualización de libICE para Solaris 8, 9, 10 y
OpenSolaris, que corrige una vulnerabilidad que podría permitir a un
atacante remoto sin privilegios causar una denegación de servicio.

El fallo, del que no se han ofrecido detalles, reside en libICE y afecta
a todas las aplicaciones que enlacen a esta librería. Un atacante remoto
sin privilegios causar una denegación de servicio a través de vectores
desconocidos.

Sun ha publicado los siguientes parches disponibles, según versión y
plataforma:
Para la plataforma SPARC:
Solaris 8 con parche 119067-11 o superior
http://sunsolve.sun.com/pdownload.do?target=119067-11&method=h 
Solaris 9 con parche 112785-65 o superior
http://sunsolve.sun.com/pdownload.do?target=112785-65&method=h 
Solaris 10 con parche 119059-46 o superior
http://sunsolve.sun.com/pdownload.do?target=119059-46&method=h 

Para la plataforma x86:
Solaris 8 con parche 119068-11 o superior
http://sunsolve.sun.com/pdownload.do?target=119068-11&method=h 
Solaris 9 con parche 112786-54 o superior
http://sunsolve.sun.com/pdownload.do?target=112786-54&method=h 
Solaris 10 con parche 119060-45 o superior
http://sunsolve.sun.com/pdownload.do?target=119060-45&method=h 
OpenSolaris versión de compilación snv_85 o superior 

Múltiples vulnerabilidades en 3Com Wireless AccessPoint

Se han encontrado múltiples vulnerabilidades en 3Com Wireless 8760 
Dual-Radio 11a/b/g PoE Access Point que podrían ser aprovechadas por un 
atacante para saltarse restricciones de seguridad, acceder a información 
sensible, inyectar código SNMP y perpetrar ataques de cross-site 
scripting. 
 
* Un fallo en el mecanismo de autenticación podría permitir a un 
atacante remoto entrar al panel de administración (si conoce las URLs 
del mismo) suplantando la IP desde la que se haya establecido el acceso 
como administrador. 
 
* Un fallo en la composición de ciertas páginas como s_brief.htm y 
s.htm, puede ser aprovechado por un atacante para acceder a información 
sensible incluida en las mismas, como la contraseña de administrador. 
 
* Un fallo de comprobación de datos de entrada al establecer el 
nombre del sistema vía SNMP puede permitir a un atacante inyectar 
código arbitrario en el navegador mientras dure la sesión entre 
cliente-servidor (cross-site scripting). Solo es posible si se 
tiene configurado SNMP con privilegios de escritura. 
 
Estas vulnerabilidades han sido reportadas para la versión de firmware 
2.1.13b05_sh aunque no se descarta que afecte a otras versiones. 
 
Actualmente no existe parche disponible para estas vulnerabilidades. 
Como contramedida se recomienda deshabilitar el interfaz web de 
administración y el acceso de escritura a SNMP. 
 
Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3693/comentar
 
Más información:

solución al crackme del décimo aniversario de "una-al-día"

Coincidiendo con el décimo aniversario de "una-al-día" publicamos hace
una semana un nuevo reto de ingeniería inversa relacionado con el
evento. La idea era analizar y entender un programa conocido como
crackme, destinado específicamente a que su propia protección software
sea sorteada. En la entrega de hoy desvelamos los lectores premiados y
cómo solucionarlo.

Los premiados que han conseguido solucionar el reto, por orden (todas
horas CET):

* Romansoft, de Madrid, el 18/11 a las 23:26
* Hernán Pereira, de Buenos Aires, el 20/11 a las 04:04
* Alejo Murillo, de Madrid el 21/11 a las 1:52
* Lionel Gómez, el 20/11 a las 18:10
* Dani kachakil, de Valencia (España) el 22/11 a las 0:27

Mención especial para Alejo, que realizó un impecable informe que
ponemos a disposición de los lectores en los enlaces de más información.

Estos primeros 5 lectores recibirán el libro "Una-al-día: 10 años de
seguridad informática". Hispasec ha publicado recientemente: "Una al
día: 10 años de seguridad informática" con motivo de la celebración
del décimo aniversario. El libro recorre los hitos más destacados de
la última década y echa una mirada al futuro más inmediato del mundo
de la (in)seguridad informática. La obra cuenta con la inestimable
colaboración, a modo de entrevistas para la ocasión, de figuras
relevantes en este terreno como son Bruce Schneider, Eugene Kaspersky,
Johannes Ullrich, Juan C. García Cuartango, Mikel Urizarbarrena, etc.

Aprovechamos para informar de que en los últimos días se ha solucionado
un error en la imprenta virtual lulu.com, que disparaba los gastos de
envío a países en Latinoamérica. Ahora el precio es mucho más razonable.
Disculpen las molestias.

Además se ha añadido un nuevo punto de venta con distintos gastos de
envío según el país, para que se pueda elegir el lugar que más convenga.

El resto de ganadores que hasta el día de hoy enviaron su solución:

* David Guerrero, de Valencia (España) el 23/11, a las 17:05
* Rafael Antonio Porras, de Madrid, el 23/11, a las 17:35
* Xacobe Rascado, de Vigo (España), el 23/11 a las 19:18
* Alejandro J. Gómez López, de Jaén (España), el 24/11 a las 18:54.

recibirán una camiseta. Gracias a todos los que han participado. La
solución al problema se encuentra en el enlace del apartado de más
información.

Revelación de información a través de ICMP en Check Point VPN-1

Se ha descubierto una vulnerabilidad en Check Point VPN-1 que podría
permitir a un atacante remoto obtener las direcciones IP de la red
interna.

El fallo reside en un manejo incorrecto de paquetes con un valor TTL
bajo. Al recibir paquetes en puertos del cortafuegos que son mapeados
a puertos internos, dichos paquetes son reescritos para enviarlos al
servidor de administración del firewall. Con un TTL corto este proceso
falla y sea crea un paquete ICMP de respuesta que contiene la dirección
interna del cortafuegos. Un atacante remoto podría obtener las
direcciones IP internas a través de paquetes especialmente manipulados.

Existe una prueba de concepto que explota esta vulnerabilidad. Check
Point ha confirmado que en breve publicará una actualización para
corregir este problema.

Concurso décimo aniversario: Crackme

Dentro del marco de la celebración por el décimo aniversario de
una-al-día, vamos a presentar un nuevo reto de ingeniería inversa
relacionado con el evento. La idea es analizar y entender un programa
conocido como crackme, destinado específicamente a que su propia
protección software sea sorteada.

La solución a este reto arrojará luz sobre nuestras costumbres diarias.
Para los ganadores habrá libros y camisetas de regalo.

El desafío consiste en generar un fichero de clave válido para este
programa. El reto tiene además un problema de diseño relacionado con el
hecho de que es un programa multi-hilo. Aquellos que además de encontrar
la clave expliquen correctamente en qué consiste el problema tendrán
prioridad sobre el resto, aunque tarden más en enviar la solución.

Las primeras personas que envíen un fichero con la clave correcta
recibirán el libro "Una-al-día: 10 años de seguridad informática" y
además una camiseta de Hispasec. Para puestos sucesivos se entregarán
también camisetas conmemorativas. Hispasec ha publicado recientemente:
"Una al día: 10 años de seguridad informática" con motivo de la
celebración del décimo aniversario. El libro recorre los hitos más
destacados de la última década y echa una mirada al futuro más inmediato
del mundo de la (in)seguridad informática. La obra cuenta con la
inestimable colaboración, a modo de entrevistas para la ocasión, de
figuras relevantes en este terreno como son Bruce Schneider, Eugene
Kaspersky, Johannes Ullrich, Juan C. García Cuartango, Mikel
Urizarbarrena, etc.

Aprovechamos para informar de que en los últimos días se ha solucionado
un error en la imprenta virtual lulu.com, que disparaba los gastos de
envío a países en Latinoamérica. Ahora el precio es mucho más razonable.
Disculpen las molestias.

El enlace para descarga del crackme es:
http://www.hispasec.com/uad/index_html 
dentro de la pestaña crackme.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3679/comentar

Actualización de seguridad para GnuTLS

El proyecto GNU ha publicado una actualización de seguridad para su
producto GnuTLS, que elimina múltiples fallos menores y una
vulnerabilidad que permitiría la falsificación de certificados X.509.

GnuTLS es una librería para la implementación del protocolo TLS
(Transport Layer Security, capa de seguridad del transporte) y de su
predecesor SSL (Secure Sockets Layer, capa de conexión segura), métodos
utilizados para ofrecer cifrado y integridad de datos en las
comunicaciones entre dos entes a través de una red informática.

Aunque tradicionalmente el uso más frecuente de SSL/TLS es para el
cifrado de las páginas web, en realidad estos protocolos de transporte
son totalmente independientes del protocolo de aplicación. Es decir, se
puede utilizar SSL/TLS para el cifrado de protocolos de aplicación como
Telnet, FTP, SMTP, IMAP o el propio HTTP.

SSL/TLS no ofrecen únicamente la capacidad de cifrar la información,
sino que también permiten a cada una de las partes identificarse de
forma fehaciente, lo que evita posibles ataques de suplantación o de
interceptación de sesiones ("man-in-the-middle").

La vulnerabilidad descubierta, podría ser aprovechada para validar un
certificado de forma automática sin que este sea realmente comprobado
en la lista de certificados válidos.

El error está causado por un fallo en la función
_gnutls_x509_verify_certificate en x509/verify.c, que se encarga de
la cadena de verificación de los certificados X.509. Debido al error,
si se añade un certificado autofirmado confiable a la lista, este será
descartado una vez validado, y el certificado situado inmediatamente
después será dado por válido sin pasar por el proceso de comprobación.

El fallo podría ser aprovechado por un atacante por medio de ataques
man-in-the-middle. Lo que le permitiría suplantar cualquier nombre y
añadirle un certificado confiable falso, que daría con que el cliente
de GnuTLS lo acepte como seguro.

Se recomienda actualizar a la versión 2.6.1 de GnuTLS no vulnerable,
disponible para su descarga desde:
http://www.gnu.org/software/gnutls/ 

Instalación y configuración de zimbra en debian etch 4.0 o ubuntu server 7.0

Muchos administradores se matan la cabeza montando un servidor de correo debido a que no es nada facil a pesar de postfix que ha humanisado mas los archivos de configuración porque sendmail es otro nivel, bueno para quitarse muchos dolores de cabeza yo recomiendo instalar zimbra como gestor de correo y aqui les pongo un ejemplo facil de como montarlo a mi me funciono perfecto.

Primero revisamos el /etc/hosts que este hay el el nombre del equipo y dominio para el que va a ser servidor de correo, deberia haber algo parecido a esto

127.0.0.1 localhost.localdomain localhost
192.168.0.110 server1.example.com server1

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

En caso de que no este el nombre del equipo y el dominio borramos lo que este hay y agregamos el dominio con nombre de host de etsa manera

echo server1.example.com > /etc/hostname

luego reiniciamos para que surtan efecto los cambios en todo el sistema

Al cargar ejecutamos hostname -f y no debe arrojar como resultado esto
server1.example.com

Luego revisamos el archivo /etc/resolv.conf qu eesten configurado los ip de nuestro servidor dns en el caso de que el servidor de correo este detras un firewall o gateway en una red privada, luego de esto desintalamos los paquetes innecesarios para nuestra instalación y que ademas dan problemas con el zimbra

apt-get remove --purge exim4 exim4-base exim4-config exim4-daemon-light

acto seguido instalamos los que si necesitamos

apt-get install libc6-i686 sudo libidn11 curl fetchmail libgmp3c2 libexpat1 libgetopt-mixed-perl libxml2 libstdc++6 libpcre3 libltdl3 ssh
ya con esto tenemos el sistema listo para em pesar con la instalación del zimbra nos cambiamos de directorio y nos descargamos la ultima versión que para el momento es 5.0.8

cd /tmp/
wget 0080709172452.tgz...

Acto seguido que lo hemos descargado empezamos con la instalación

tar xvfz zcs-5.0.8_GA_2462.DEBIAN4.0.20080709172452.tgz
cd zcs-5.0.8_GA_2462.DEBIAN4.0.20080709172452
./install.sh -l

En este paso nos hara una serie de preguntas

Checking for prerequisites...
NPTL...FOUND
sudo...FOUND sudo-1.6.8p12-4
libidn11...FOUND libidn11-0.6.5-1
fetchmail...FOUND fetchmail-6.3.6-1etch1
libpcre3...FOUND libpcre3-6.7+7.4-2
libgmp3c2...FOUND libgmp3c2-2:4.2.1+dfsg-4
libxml2...FOUND libxml2-2.6.27.dfsg-2
libstdc++6...FOUND libstdc++6-4.1.1-21
openssl...FOUND openssl-0.9.8c-4etch1
libltdl3...FOUND libltdl3-1.5.22-4
Prerequisite check complete.
Checking for standard system perl...
perl-5.8.8...FOUND standard system perl-5.8.8

Install zimbra-ldap [Y] Y
Install zimbra-logger [Y] Y
Install zimbra-mta [Y] Y
Install zimbra-snmp [Y] Y
Install zimbra-store [Y] Y
Install zimbra-apache [Y] Y
Install zimbra-spell [Y] Y
Install zimbra-proxy [N] N

The system will be modified. Continue? [N] Y

Main menu

1) Common Configuration:
2) zimbra-ldap: Enabled
3) zimbra-store: Enabled
+Create Admin User: yes
+Admin user to create: admin@server1.example.com
******* +Admin Password UNSET
+Enable automated spam training: yes
+Spam training user: spam.m0bqyoayc@server1.example.com
+Non-spam(Ham) training user: ham.ygch0qyz1@server1.example.com
+Global Documents Account: wiki@server1.example.com
+SMTP host: server1.example.com
+Web server HTTP port: 80
+Web server HTTPS port: 443
+Web server mode: http
+IMAP server port: 143
+IMAP server SSL port: 993
+POP server port: 110
+POP server SSL port: 995
+Use spell check server: yes
+Spell server URL: http://server1.example.com:7780/aspell.php

4) zimbra-mta: Enabled
5) zimbra-snmp: Enabled
6) zimbra-logger: Enabled
7) zimbra-spell: Enabled
Default Class of Service Configuration:
r) Start servers after configuration yes
s) Save config to file
x) Expand menu
q) Quit

Address unconfigured (**) items (? - help)

Aqui tienes que elegir la opción numero 3 y ponerle una clave al usuario admin no menor de 6 digitos, cn este usuario es que vamos a trabajar siempre para administrar nuestro servidor

Store configuration

1) Status: Enabled
2) Create Admin User: yes
3) Admin user to create: admin@server1.example.com
** 4) Admin Password UNSET
5) Enable automated spam training: yes
6) Spam training user: spam.m0bqyoayc@server1.example.com
7) Non-spam(Ham) training user: ham.ygch0qyz1@server1.example.com
Global Documents Account: wiki@server1.example.com
9) SMTP host: server1.example.com
10) Web server HTTP port: 80
11) Web server HTTPS port: 443
12) Web server mode: http
13) IMAP server port: 143
14) IMAP server SSL port: 993
15) POP server port: 110
16) POP server SSL port: 995
17) Use spell check server: yes
18) Spell server URL: http://server1.example.com:7780/aspell.php

Select, or 'r' for previous menu [r]

Enter "4" (without the quotes) and press "Enter" to modify the admin password. Now you'll be asked for the new password.

Password for admin@server1.example.com (min 6 characters): [TR9Fm7uD]

Aqui introduces el password para el usuario admin

Main menu

1) Common Configuration:
2) zimbra-ldap: Enabled
3) zimbra-store: Enabled
4) zimbra-mta: Enabled
5) zimbra-snmp: Enabled
6) zimbra-logger: Enabled
7) zimbra-spell: Enabled
Default Class of Service Configuration:
r) Start servers after configuration yes
s) Save config to file
x) Expand menu
q) Quit

*** CONFIGURATION COMPLETE - press 'a' to apply
Select from menu, or press 'a' to apply config (? - help)

Con esot ya tenemos casi listo nuestro servidor de correo nos hara una preguna sobre donde y en que archivo va a sarvar los cambio le damos a todo enter

Save configuration data to a file? [Yes] Enter
Save config in file: [/opt/zimbra/config.5422]
Saving config in /opt/zimbra/config.5422...done.
The system will be modified - continue? [No] Y

Operations logged to /tmp/zmsetup.02062008-135354.log
Setting local config values...done.
Setting up CA...done.
Creating SSL certificate...done.
Initializing ldap...done.
Setting replication password...done.
Setting Postfix password...done.
Setting amavis password...done.
Deploying CA to /opt/zimbra/conf/ca ...done.
Creating server entry for server1.example.com...done.
Setting spell check URL...done.
Setting service ports on server1.example.com...done.
Adding server1.example.com to zimbraMailHostPool in default COS...done.
Installing skins...
hotrod
lavender
waves
steel
sky
bones
yahoo
sand
lemongrass
beach
bare
done.
Setting zimbraFeatureIMEnabled=FALSE...done.
Setting zimbraFeatureTasksEnabled=TRUE...done.
Setting zimbraFeatureBriefcasesEnabled=TRUE...done.
Setting zimbraFeatureNotebookEnabled=TRUE...done.
Setting MTA auth host...done.
Setting TimeZone Preference...done.
Creating domain server1.example.com...done.
Creating user admin@server1.example.com...done.
Creating postmaster alias...done.
Creating user wiki@server1.example.com...done.
Creating user spam.m0bqyoayc@server1.example.com...done.
Creating user ham.ygch0qyz1@server1.example.com...done.
Setting spam training accounts...done.
Initializing store sql database...done.
Setting zimbraSmtpHostname for server1.example.com...done.
Initializing logger sql database...done.
Initializing mta config...done.
Configuring SNMP...done.
Setting services on server1.example.com...done.
Setting up zimbra crontab...done.
Setting up syslog.conf...done.

After all you'll be asked if you want to notify Zimbra of your installation. Press "Enter" if you want to do that, or enter "N" (without the quotes) and press "Enter" if you disagree to that. Afterwards the system will be initialized - it should look like this:

Starting servers...done.
Checking for deprecated zimlets...done.
Installing zimlets...
com_zimbra_date
com_zimbra_url
com_zimbra_cert_manager
com_zimbra_phone
com_zimbra_search
com_zimbra_local
com_zimbra_email
done.
Initializing Documents...done.
Restarting mailboxd...done.

Moving /tmp/zmsetup.02062008-135354.log to /opt/zimbra/log

Por ultimo para verificar que todo este bien nos cambiamos al usuario zimbra y verificamos que todos los servicios esten arriba de la siguiente manera

su - zimbra
zmcontrol status Esto nos deberia de arrojar como resultado lo siguiente
Host server1.example.com
antispam Running
antivirus Running
ldap Running
logger Running
mailbox Running
mta Running
snmp Running
spell Running
stats Running

En caso de no arrojar un resultado parecido a este intentamos levantar los servicios asi

zmcontrol start

Si todo ha ido bien tenemos listo nuestro servidor de correo sino es porque te slataste algun paso del manual.

Para empezar a administrar nuestro servidor entramos a la consola administrativa de la siguiente manera https://server1.example.com:7071/zimbraAdmin/ impotante que "A" de Admin este en mayuscula si no esta en mayuscula no va a entrar en la consola aqui nos pide un usuraio y una clave el usuario es admin y la clave es la uqe pusimos hace ratos atras, la consola no la voy a explicar porque ella se explica sola es muy facil y eficiente, todo lo que resta es crear los usuarios y los dominios si vas a hacer el servidor multidominio y listo.

Para entrar en modo usuario entras de la siguiente manera http://server1.example.com introduces el usuario en este formato usuario@midominio.com y la clave si no le pones el @dominio no va a entrar debido a que puede ser servidor multi dominio, como información adicional les digo que antes de empezar a instalar el zimbra tienen que tener el DNS bien configurado apuntando hacia la ip de nuestro servidor de correo porque sino el zimbra les va a dar error en la instalación.

Diversas vulnerabilidades en IBM DB2 9.x

Se han encontrado múltiples vulnerabilidades en IBM DB2, algunas son de
impacto desconocido y otras podrían ser aprovechadas por un atacante
remoto para causar una denegación de servicio o revelar información
sensible.

* La primera vulnerabilidad está causada por un error en la función
"SQLNLS_UNPADDEDCHARLEN()" que podría causar una violación de acceso
(segmentation fault) en servidor DB2 al intentar acceder a una parte de
memoria para la que no se tienen permisos.

* Las vistas (views) y los disparadores (triggers) deberían estar
marcados como no operativos o ser descartados en el Native Managed
Provider para .NET si los objetos no pueden ser mantenidos por quien los
ha definido.

* Un error no especificado en los servicios de ordenación/listado podría
ser explotado para revelar ciertas cadenas relacionadas con la
contraseña de conexión.

Las vulnerabilidades están confirmadas para la versiones anteriores a la
9.x FP6 de IBM DB2.

Se recomienda aplicar el Fixpack 6, disponible desde:
http://www.ibm.com/support/docview.wss?rs=71&uid=swg27007053

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3654/comentar

Dos vulnerabilidades en la rama 2.x de OpenOffice permiten ejecución de código

OpenOffice.org ha publicado una actualización para la rama 2.x de
OpenOffice. Soluciona dos problemas de seguridad que podrían permitir a
un atacante ejecutar código si se procesan documentos especialmente
manipulados con una versión vulnerable.

* Uno de los fallos se trata de un desbordamiento de memoria intermedia
basado en heap en el intérprete de ficheros EMF.

* El segundo fallo se debe a un desbordamiento de enteros a la hora de
procesar registros META_ESCAPE en ficheros WMF.

Ambos fallos podrían permitir la ejecución de código arbitrario con los
permisos del usuario bajo el que se usara la aplicación.

Ambos también, están relacionados con problemas a la hora de procesar el
formato Windows Meta File y Extended (o Enhanced) Windows Metafile
Format. Estos formatos de imagen se hicieron especialmente famosos a
raíz de la vulnerabilidad descubierta a finales de 2005 en Microsoft
Windows y que infectó a millones de usuarios.

La reciente versión 3.0 de OpenOffice no se ve afectada.

No se han dado detalles técnicos ni parece existir exploit público. Se
recomienda actualizar a la versión OpenOffice 2.4.2. Todas las
anteriores son vulnerables.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3660/comentar

Más información:

Manipulated EMF files can lead to heap overflows and arbitrary code execution
http://www.openoffice.org/security/cves/CVE-2008-2237.html

Una-al-día cumple 10 años

Hoy, 28 de octubre, se cumple el décimo aniversario de "una-al-día",
primer diario de información técnica sobre seguridad informática
en español. Una década informando puntualmente sobre virus,
vulnerabilidades, fraudes, alertas, y reflexiones sobre la seguridad
en Internet. 3.657 noticias. Aniversarios anteriores en Hispasec se
han caracterizado por una sobria mención o directamente han pasado
desapercibidos. En esta ocasión, hemos decidido festejar esta cifra
tan redonda con algunas sorpresas.

Diez años en la Red es mucho tiempo. Ha sido necesario sobrevivir al
cambio en el modelo económico sufrido a principios de esta década (que
a tantos servicios web dejó atrás), o a la avalancha y saturación de
información que está proporcionando hoy la web 2.0... se han producido
muchos cambios en Internet en general y en la seguridad en particular,
y los hemos intentado reflejar día a día, informando de la única forma
que sabemos: con independencia y honestidad. Estamos muy orgullosos
de seguir produciendo una-al-día y poder ofrecerlas a nuestros
suscriptores, que entre todos los canales de distribución, suman
muchas decenas de miles.

Cuando Bernardo Quintero escribió la primera una-al-día: "28/10/1998
Service Pack 4, los problemas de la solución" no podía ni imaginar que
diez años después el servicio continuaría, que lo haría en Hispasec,
proyecto web fundado exactamente dos meses después del primer envío, a
partir del éxito de los boletines iniciales. En aquel momento, otros
proyectos posteriores como Virustotal.com eran solo un vago concepto
todavía. Pero sobre todo, no podíamos imaginar que 10 años después
una-al-día e Hispasec seguiría siendo un respetado referente en
seguridad para muchos hispanohablantes o que Virustotal.com se
convertiría en un estándar de facto para el envío de malware en todo el
mundo, que procesa 60.000 muestras cada día. Es un éxito que agradecemos
y que asumimos con responsabilidad.

Es gratificante pensar que en estos diez años, hemos llegado incluso a
un cambio generacional. Muchos profesionales reconocidos eran apenas
adolescentes cuando comenzó el servicio de publicación diario. Hoy desde
sus puestos de trabajo, todavía confían en la información que a diario
les ofrece una-al-día.

Este décimo aniversario pensamos que merece una mención especial. Desde
agosto, hemos conseguido arañar algo de tiempo de nuestras agendas para
preparar varias sorpresas que esperamos que agraden a todo el mundo. Han
supuesto un importante esfuerzo y se han concebido como regalo especial
para todos los seguidores del boletín diario.

Durante las próximas semanas, pedimos a nuestros lectores que estén
especialmente atentos a los boletines, porque iremos descubriendo las
sorpresas en sucesivas publicaciones.

Gracias a todos. En especial, a nuestros fieles suscriptores: desde la
primera persona que leyó el boletín en octubre de 1998, hasta el usuario
del último correo que se ha suscrito al servicio hace apenas unos
minutos.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3657/comentar

Activar los killbits y el índice de explotabilidad, novedades en los boletines de Microsoft

Microsoft está siguiendo una nueva política con la que intenta mejorar
sus boletines de seguridad. Este mes ha introducido un nuevo valor
llamado "índice de explotabilidad" (exploitability index) que indica
las posibilidades de que se cree un exploit para cada vulnerabilidad.
Además, se está proponiendo (por fin) activar el mayor número de
killbits posibles para evitar ataques a través de ActiveX vulnerables.

En octubre Microsoft ha incluido por primera vez en sus boletines el
"exploitability index", un valor que intenta predecir la posibilidad de
que los atacantes creen código capaz de aprovechar la vulnerabilidad.
Los valores posibles que asignará Microsoft son:

* Consistent exploit code likely: Es probable la creación de un exploit
consistente.
* Inconsistent exploit code likely: Es probable la existencia de un
exploit incosistente.
* Functioning exploit code unlikely: Es improbable la existencia de un
exploit funcional.

Refiriéndose con "consistencia" a las probabilidades que funcione bajo
la mayoría de las circunstancias y la mayor parte de las veces. Esta
forma de puntuar el riesgo es exclusiva de Microsoft, y evaluada solo
por su parte.

Por ejemplo, en esta última tanda de boletines, se resuelven 20
vulnerabilidades. Según Microsoft 8 tienen posibilidades de que se cree
un exploit consistente para ellas, y cuatro son poco probables de ser
aprovechadas. Para otras incluso, como el fallo en Windows Printing
Service de Internet Information Services (IIS) Web server, se tiene
constancia de que están siendo activamente aprovechadas. Para una de las
que predijo la posibilidad de un exploit consistente, efectivamente se
ha publicado posteriormente código capaz de aprovechar el fallo.

Microsoft sigue resistiéndose sin embargo a añadir a sus boletines el
valor CVSS (Common Vulnerability Scoring System) de cada vulnerabilidad.
Se trata de un estándar que gradúa la severidad de manera estricta a
través de fórmulas establecidas y que ya siguen Oracle y Cisco entre
otros. Cuando fue creado en 2005, la compañía apoyó la iniciativa, pero
más tarde adujo que su sistema propio de graduación era correcto, y
nunca ha terminado de apoyar este estándar.

Por último, destacar que Microsoft últimamente está incluyendo boletines
oficiales destinados a activar los killbits de componentes ActiveX,
tanto propios como de terceros. Esto es muy positivo. Los ActiveX suelen
ser librerías de Microsoft o de terceros que, en muchas ocasiones,
sirven de puerta para entrar en el sistema a través de Internet
Explorer, gracias a los fallos de seguridad de los propios ActiveX. El
peligro está en que el navegador es capaz de invocarlos, aunque no sea
realmente necesario para cumplir su función. Al activar el killbit, se
asegura que Internet Explorer no puede llamarlos y se anula así un
importante vector de ataque. Al difundir esta activación de killbits
a través de las actualizaciones oficiales de Microsoft, se aseguran
mitigar potenciales problemas con una difusión mucho más extensa que
si lo hiciera el propio fabricante del ActiveX.

Aunque es obligación de los programadores de ActiveX ser precavidos
y activar ese killbit, en la mayoría de las ocasiones sólo una
vulnerabilidad les hace reaccionar. Usar los parches de Microsoft para
anular este vector de ataque, puede impedir muchos problemas de manera
mucho más rápida y mayoritaria. En esta última tanda de boletines (como
medida extra de precaución) se han activado los killbits incluso de
ActiveX propios de Microsoft que ya habían sufrido vulnerabilidades y
para los que existían parches.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3648/comentar

Más información:

Microsoft Exploitability Index
http://technet.microsoft.com/en-us/security/cc998259.aspx

Corregida una vulnerabilidad de ejecución remota de código en Graphviz

El investigador de IBM, Roee Hay, ha descubierto recientemente una
vulnerabilidad en Gralphviz que podría ser aprovechada para causar una
denegación de servicio o ejecutar código arbitrario en el sistema, si un
usuario intenta abrir un archivo DOT especialmente manipulado.

Graphviz es un software gratuito de visualización de grafos, de código
abierto y que se distribuye bajo licencia Common Public License v.1.0.
El programa permite realizar una descripción de grafos en formato de
texto (lenguaje DOT) y obtener diagramas en múltiples formatos
distintos. Desde la página web de Graphviz se pueden descargar los
paquetes para Windows, Mac, FreeBSD, Solaris y para distintas
distribuciones de Linux.

La vulnerabilidad está causada por una falta de comprobación de límites
del array "Gstack" en la función "push_subg" de "lib/graph/parser.c".
Esto podría ser aprovechado para desbordar el array causando una
corrupción de memoria que podría ser aprovechada para ejecutar código
arbitrario.

A continuación se puede ver la porción de código vulnerable,
perteneciente a la versión 2.20.2 de Graphviz:

static void push_subg(Agraph_t *g) {
G = Gstack[GSP++] = g;
}

Y la función corregida, perteneciente a la última versión (v.2.20.3):

static void push_subg(Agraph_t *g) {
if (GSP >= GSTACK_SIZE) {
agerr (AGERR, "Gstack overflow in graph parser\n"); exit(1);
}
G = Gstack[GSP++] = g;
}

Si bien es cierto que la vulnerabilidad era evitable, y que la
modificación requerida parece trivial, cabe reseñar la eficacia del
grupo de desarrolladores del proyecto, ya que pasó tan solo un día desde
que fueron informados de la vulnerabilidad hasta que pusieron a
disposición de sus usuarios una versión actualizada y no vulnerable.

Se recomienda actualizar a la versión 2.20.3 de Graphviz, disponible
para las distintas plataformas desde:
http://www.graphviz.org/Download..php

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3640/comentar

Denegación de servicio a través de UFS en Sun Solaris 8, 9 y 10

Se ha encontrado una vulnerabilidad en Sun Solaris 8, 9 y 10 y
OpenSolaris que podría permitir a un atacante provocar una denegación de
servicio.

El fallo se debe a un problema no especificado en la implementación de
las ACL (Access Control List) del sistema de ficheros UFS. Un atacante
local sin privilegios podría provocar un "panic" en el sistema y hacer
que dejase de responder.

No existe parche oficial para las versiones de Sun Solaris, por lo que
se recomienda restringir el acceso a usuarios no confiables. Para
OpenSolaris se recomienda actualizar a OpenSolaris build snv_100 o
posterior.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3640/comentar

Ejecución remota de código en impresoras multifunción Xerox

Se ha encontrado una vulnerabilidad en el controlador de red/ESS de las
impresoras multifunción WorkCentre de Xerox que podría ser explotada por
un atacante de la red local para ejecutar código arbitrario en la
impresora.

La vulnerabilidad está causada por un desbordamiento de búfer en Samba
al manejar respuestas SMB (Service Message Block) remotas. Esto podría
ser aprovechado por un atacante de la red local para tomar el control de
la impresora.

Samba es una implementación Unix "Open Source" del protocolo
SMB/NetBIOS, utilizada para la compartición de archivos e impresora en
entornos Windows. Gracias a este programa, se puede lograr que máquinas
Unix y Windows convivan amigablemente en una red local, compartiendo
recursos comunes.

Si un atacante consigue tomar el control de una impresora podría cambiar
la configuración de la misma; pero además podría conseguir cierta
información sensible, ya que tendría acceso a la memoria del dispositivo
donde residen aquellos documentos copiados o imprimidos recientemente.
Esto podría suponer un riesgo a tener en cuenta sobre todo en entornos
corporativos.

La vulnerabilidad está confirmada para las siguientes versiones de
impresoras multifunción: Xerox WorkCentre: 232, 238, 245, 255, 265, 275,
7655, 7665, 7675, 5623, 5635, 5645, 5655, 5665, 5675 y 5687. Xerox
WorkCentre Pro: 232, 238, 245, 255, 265 y 275.

El fabricante recomienda consultar la tabla de versiones vulnerables
(disponible en el boletín de seguridad) y aplicar el parche P36v1,
disponible para su descarga desde:
http://www.xerox.com/downloads/usa/en/c/cert_P36v1_WCP275_WC7675_WC5687_Patch.zip

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3633/comentar

Más información:

Xerox Security Bulletin XRX08-009:
Software update to address Network Controller vulnerability
http://www.xerox.com/downloads/usa/en/c/cert_XRX08_009.pdf

Algunas preguntas frecuentes sobre la supuesta vulnerabilidad en el protocolo base de la Red

Ayer publicábamos un boletín sobre la supuesta vulnerabilidad
descubierta por Outpost24 que podría permitir la caída de cualquier
aparato con comunicación en la Red. Disponemos ahora de más información,
que ayer mismo publicaban fuentes oficiales, sobre el asunto. Además,
aprovechamos para corregir algunos errores.

¿El fallo es nuevo? ¿Por qué "supuesta"?

Probablemente no. Aunque no se conocen los detalles, todo son
conjeturas. Quizás sea una nueva forma de aprovechar una vieja debilidad
conocida del TCP/IP. "Supuesta" es simplemente porque no ha quedado
demostrado todavía por terceras partes independientes.

¿Aprovechar el fallo requiere de un envío continuado de paquetes?

Sobre esto ha habido cierta confusión. Algunos apuntan a que es
necesario bombardear de forma continuada y con un cierto tipo de
paquetes al servidor. Otros que con sólo unos minutos de tráfico se
puede hacer que el sistema quede sin recursos. Según Robert E. Lee de
Outpost 24, depende del dispositivo. Lo normal es que permanezcan caídos
mientras dure el ataque (como ocurre con un DDoS, por ejemplo), pero se
han dado casos en que se agotan sus recursos y se necesita un reinicio
con una mínima cantidad de tráfico.

¿Desactivando la protección "SYN Cookies" se previene el problema?

No. Simplemente se volvería a ser más vulnerable a ataques de tipo SYN
Flood

¿Todos los dispositivos son vulnerables?

Según los descubridores, depende mucho del tipo de ataque y del
dispositivo. Es posible que el dispositivo tenga que ser reiniciado,
pero no siempre se llega a ese punto.

¿El problema está en TCP/IP?

Como nos han comunicado algunos lectores de una-al-día, el problema está
en el protocolo TCP/IP, no exclusivamente en IP, como se apuntaba
erróneamente en el boletín anterior.

¿Por qué ahora todas estas alarmas catastrofistas?

Aunque dicen conocer el problema desde 2005, Outpost24 se habrá decidido
a hacer público este asunto precisamente ahora por varias razones.
Primero para intentar proteger y mejorar el sistema. (¿Por qué no?)
Kaminsky lo hizo con el fallo de DNS. El problema del BGP no tuvo tanta
repercusión mediática pero llamó mucho la atención. La compañía quizás
se ha animado finalmente a hacer público sus descubrimientos tras
comprobar la publicidad que este tipo de declaraciones puede
reportarles. Es evidente que, como siempre ha ocurrido en la publicación
de vulnerabilidades novedosas, la búsqueda de notoriedad y prestigio
juegue un papel importante, aunque no resta importancia al
descubrimiento en sí. Por cierto, también se dijo en la anterior
una-al-día que era una empresa finlandesa cuando en realidad es sueca.

¿Están exagerando?

El hecho de ofrecer un poco de información en forma de "cebo" y prometer
el resto en conferencias posteriores asegura una buena cantidad de
especulación y por tanto mantener a la empresa en boca de todos durante
unas semanas. Esto no resta seriedad al potencial fallo.

¿Es para tanto?

Matizan sus afirmaciones hablando siempre de "bajo circunstancias
concretas" lo que da a entender que no es tan sencillo reproducirlo.
Además, si se trata de una denegación de servicio a través de una
inundación de paquetes continuados, hoy en día tenemos los DDoS más
potentes que nunca a través de las botnets más grandes del momento.
Miles de sistemas zombi infectados bombardean con tráfico (legítimo) las
páginas para intentar echarlas abajo, y resulta bastante efectivo.
Recurrir a este tipo de vulnerabilidades constituyen una novedad, pero
en la práctica existen ya métodos que pueden dar iguales o mejores
resultados a los atacantes. Si, hipotéticamente, se hicieran públicos
los detalles de este fallo y sacaran una herramienta que permitiese a
cualquiera tumbar un servidor con un solo click, protegerse sería
sencillo: se bloquearía el acceso desde esa IP... así que para que fuese
efectivo el atacante tendría que recurrir a diferentes IPs... o sea, a
una botnet. Fyodor, creador de nmap, opina que no es para tanto, pero
desde Outpost24, se le ha dicho que no lleva del todo razón en sus
suposiciones.

¿Internet "se rompe"?

Este tipo de alertas sobre problemas de base deberían servir para
alertar sobre la gran dependencia que tiene hoy en día Internet de
protocolos obsoletos. DNS y SMTP por ejemplo, son protocolos antiguos
que no tienen en absoluto en cuenta la seguridad, aun así son los más
usados en la Red. Estas alertas no deberían servir para vaticinar
catástrofes y que cunda el pánico, sino para que todos seamos
conscientes de que existe la posibilidad de que se vaya necesitando un
cambio en la base de la Red para protegerla convenientemente.

¿Sirven de algo estas alertas catastrofistas?

Si se toman con calma, sí. Por ejemplo, el descubrimiento de Kaminsky ha
servido para retomar con fuerza el debate sobre el uso estandarizado de
DNSSEC para proteger adecuadamente al inseguro DNS. Aunque será extraño
que se implante a corto plazo. Requiere de una infraestructura de
certificados y autoridades confiables que puede resultar compleja, e
invita al control por parte de una sola gran autoridad certificadora. Es
incluso probable que el debate quede en nada una vez más. Las grandes
modificaciones son siempre complicadas y costosas aunque quizás cada vez
más necesarias.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3632/comentar

IPSupuesta vulnerabilidad en el protocolo ip pone (de nuevo) en riesgo a toda la Red

Una empresa finlandesa llamada Outpost 24 dice haber descubierto un
fallo en el Internet Protocol (IP) que puede provocar una denegación de
servicio en todo dispositivo que lo use. Teniendo en cuenta que es la
base sobre la que se sustenta toda Internet, es equivalente a decir que
se puede provocar la caída de cualquier aparato con comunicación en la
Red. Es la tercera "gran alerta" del año. ¿Necesita Internet una puesta
a punto?

En realidad ni siquiera se podría llamar "denegación de servicio" tal y
como lo conocemos hoy en día. Más bien se trataría de una especie de
(mítico) "ping de la muerte" en el que, con muy poco tráfico (10
paquetes por segundo) se podría llegar a colapsar cualquier dispositivo
que implemente la especificación del protocolo base. Al parecer se
trataría de uno de los mayores problemas detectados en la Red que la
volvería insostenible de forma relativamente sencilla.

No se han ofrecido por tanto muchos más detalles. Parece que el problema
surgió durante el escaneo de varios millones de sitios en Internet.
Alguno de estos tests (realizados con la herramienta Unicornscan) hacía
que los sistemas dejaran de responder, y tras una investigación se
concluyó que existía un problema en todas las implementaciones de la
pila TCP/IP. Aunque afecta de distinta manera, se supone que todas son
vulnerables y que todavía no han encontrado ningún dispositivo que no
puedan bloquear.

Los investigadores han conocido este problema desde 2005. Según dicen,
no han podido encontrar por el momento una solución válida, pero tampoco
quieren difundir los detalles por el peligro que supondría el
conocimiento público. Advierten que, incluso con IPv6 el problema podría
ser incluso más grave.

Darán más detalles sobre el problema el 17 de octubre, durante una
conferencia en Helsinki. Afirman tener una herramienta llamada
sockstress capaz de "tumbar" cualquier dispositivo. Aunque la
información es confusa (y habría que tomarla con cautela mientras no se
tengan detalles), parece que el problema está directamente relacionado
con la técnica de las "SYN cookies". Se utilizan precisamente para
evitar que un atacante pueda realizar una inundación de paquetes SYN.
Básicamente se "recuerda" con esta cookie a quien ha realizado la
conexión y se evita que se falsee la dirección y se perpetre el conocido
ataque (abriendo conexiones a medio realizar que consumen memoria y
agotando los recursos del dispositivo).

Es la tercera gran vulnerabilidad del año que pone en peligro a toda la
Red. En primer lugar fue Kaminsky con su problema DNS. El 8 de julio
todos los grandes y pequeños fabricantes parcheaban sus sistemas DNS.
Kaminsky había descubierto meses antes un fallo que permitía falsificar
cualquier IP asociada a un dominio. Poco después en agosto, durante la
Black Hat, se habla de nuevo de la mayor vulnerabilidad de Internet,
cuando Tony Kapela y Alex Pilosov demostraron una nueva técnica que
permite interceptar el tráfico de Internet a una escala global.
Cualquiera con un router BGP podría interceptar el tráfico de cualquier
gran nodo y devolverlo (modificado o no) de forma transparente.

Y vuelve a ocurrir, repitiendo prácticamente el mismo escenario. En los
tres casos se trata de un problema de diseño de un protocolo creado
muchos años antes. En los tres casos parece haber una demostración
empírica de un problema conocido pero cuyas posibilidades o puesta en
práctica se suponía imposible hasta la fecha... Incluso el hecho de
revelar detalles en una conferencia posterior con la que se crea una
gran expectación. Como le ocurrió a Kamisky, es posible que todos los
detalles del problema salgan a la luz antes de lo esperado si algún
investigador decide juntar todas las pistas ofrecidas por Outpost 24.

Es más que posible que aunque los detalles fueran conocidos desde hace 3
años, haya sido precisamente lo ocurrido con el fallo DNS y con BGP lo
que haya animado a los investigadores a darle publicidad precisamente
ahora. Kaminsky demostró que se puede realizar una actualización masiva
y coordinada entre todos los grandes fabricantes y mantener en secreto
los detalles de un grave problema (siempre que no se divulgue su
existencia).

Nos encontramos posiblemente también ante una nueva era en la Red en la
que, a través de estos graves errores puestos sobre la mesa, estamos
cuestionando su sostenibilidad tal y como la conocemos. Usamos
protocolos diseñados, cuando menos, hace 20 y 30 años. Los ingenieros
estaban mucho más sorprendidos por el hecho de que la Red simplemente
funcionase que preocupados por la seguridad. Hacer que un trozo concreto
de información digital concreta llegase de un punto a otro del planeta
era algo demasiado fantástico como para complicarlo previniendo si
alguien la iba a podía modificar, alterar u obtener de forma ilegítima.
Posteriormente, sobre estos débiles pilares, se ha construido algo
muchísimo más complejo y unido millones de personas y dispositivos con
muy distintas motivaciones. Para abarcar toda esta explosión, se ha ido
parcheando sobre la marcha un monstruo gigante con pies de barro que, a
la vista de estos tres recientes acontecimientos (y de otras
preocupaciones de largo recorrido, como el malware ganando la batalla a
los antivirus), necesita una clara revisión y puesta a punto.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3631/comentar


New attacks reveal fundamental problems with TCP
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1332898,00.html

Ejecución remota de código a través de WinZip en Windows 2000

 
Se han encontrado múltiples problemas de seguridad en WinZip 11.x que 
podrían ser aprovechadas por un atacante remoto para ejecutar código 
arbitrario en sistemas Windows 2000. 
 
A pesar de que existen alternativas gratuitas y de código abierto, 
WinZip es actualmente unos de los compresores más extendidos debido a su 
modo sencillo de trabajar con los archivos y a que permite el manejo de 
numerosos formatos de compresión, siendo el .zip el usado por defecto. 
 
Las vulnerabilidades encontradas están causadas porque WinZip 11.x 
incluía en la carpeta del programa una versión vulnerable de la librería 
GDI+ de Windows (gdiplus.dll) para procesar archivos de imagen. –La 
versión 11.0 la incluía siempre aunque las 11.1 y 11.2 sólo si los 
equipos estaban basados en Windows 2000-. Aprovechándose de esta 
circunstancia, un atacante remoto podría ejecutar código arbitrario si 
un usuario hiciera uso del modo de visualización para intentar acceder 
una imagen especialmente modificada contenida en un archivo zip. El 
ataque sería efectivo solamente sobre sistemas basados en Windows 2000 
ya que son los únicos que harían uso de la librería obsoleta situada en 
la carpeta de WinZip en vez de usar la versión de la misma librería que 
viene junto con el sistema operativo, y que fue actualizada en el último 
ciclo de actualizaciones. 
 
En el boletín de seguridad MS08-052 publicado por Microsoft el día 9 de 
septiembre, se daban a conocer los detalles de las cinco 
vulnerabilidades críticas en el componente GDI+ de Windows que podrían 
ser aprovechadas para ejecutar código arbitrario. Son las siguientes: 
 
* Un desbordamiento de búfer basado en heap cuando GDI+ procesa de forma 
incorrecta el tamaño de los gradientes manejados por la librería de 
enlaces a vectores gráficos. 
 
* Un error al manejar la reserva de memoria cuando se procesa un archivo 
de imagen EMF (Enhanced Metafile) especialmente manipulado que podría 
causar una corrupción de memoria. 
 
* Un problema de seguridad al procesar los archivos GIF (Graphics 
Interchange Format) especialmente manipulados. 
 
* Un desbordamiento de búfer en GDI+ causado por un fallo al reservar 
memoria cuando se analiza un archivo WMF (Windows Metafile) 
especialmente manipulado. 
 
* Un desbordamiento de enteros al procesar de forma inadecuada ciertas 
cabeceras mal formadas en archivos BMP especialmente manipulados. 
 
El pasado 25 de Septiembre WinZip Computing lanzaba WinZip 11.2 SR-1, 
una actualización de seguridad para los usuarios de las versiones 11.x 
de WinZip en la que se reemplaza la versión obsoleta de gdiplus.dll por 
la versión actualizada, no vulnerable a los citados problemas. La URL de 
descarga de WinZip 11.2 SR-1 (Build 8261) es: 
http://download.winzip.com/nrb/winzip112.exe 
 
La versión 12 de WinZip, que tampoco sería vulnerable, se puede obtener 
desde: 
http://update.winzip.com/downwz.htm 
 
Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3630/comentar