viernes, 31 de julio de 2009

Denegación de servicio a través de RTP en Asterisk 1.6.x

Se ha detectado un error a la hora de procesar el protocolo RTP en Asterisk que podría provocar una referencia a puntero nulo. Esto podría ser usado por un atacante remoto sin autenticar para causar una denegación de servicio a través de un paquete RTP especialmente manipulado.

Asterisk es una aplicación diseñada para poder crear una centralita telefónica usando un ordenador. Inicialmente fue desarrollada por Digium y diseñada para el sistema operativo Linux. Actualmente se distribuye bajo licencia GPL y está disponible además para BSD, MacOSX, Solaris y Windows. Asterisk ofrece la posibilidad en su configuración ("dialplan") de escribir todo tipo de scripts ejecutables según diferentes eventos que ocurran a través del teléfono. Soporta gran cantidad de protocolos relacionados con VoIP como son SIP, H.323, IAX y MGCP.

RTP (Real-time Transport Protocol) es un protocolo usado para comunicaciones en tiempo real que funciona sobre UDP. Este protocolo se usa en streaming de video y/o audio y suele ir junto a RTCP (Real-time Transport Control Protocol) que añade funciones de control a RTP al no tratarse de un protocolo orientado a la conexión.

Solo se ve afectada por esta vulnerabilidad la rama 1.6.x de Asterisk.


Victor Antonio Torre
vtorre@hispasec.com


Más información:

Parche por SVN en:
http://downloads.asterisk.org/pub/security/AST-2009-004-1.6.1.diff.txt

Asterisk Project Security Advisory ? AST-2009-004
http://downloads.asterisk.org/pub/security/AST-2009-004.html

jueves, 30 de julio de 2009

Fallo de seguridad en los servidores ISC BIND 9

Se ha encontrado un fallo de seguridad en la función "dns_db_findrdataset", localizada en el archivo fuente "db.c", que podría ser aprovechado por un atacante remoto sin autenticar para causar una denegación de servicio a través de un paquete de actualización dinámica especialmente manipulado que contenga un registro ANY en la sección "PREREQUISITE".

Se ha detectado que el fallo está siendo activamente explotado y aunque solo afectaría en exclusividad a servidores configurados como maestros, la vulnerabilidad persiste en aquellos servidores maestros aunque no tengan configuradas las actualizaciones dinámicas.

BIND 9 es el servidor DNS más extendido en Internet. Creado originalmente por cuatro estudiantes de la universidad de Berkeley (California), en los años 80, actualmente es mantenido por el consorcio ISC. El código de BIND se reescribió desde cero en parte debido a las numerosas vulnerabilidades que fueron apareciendo y la dificultad para implementar mejoras con la base de código anterior.

El fallo fue publicado el 28 de julio y ya se dispone de una actualización, aunque como anécdota ocurrieron un par de despistes, achacables a la razonable celeridad con la que actuaron al publicarla.

En primer lugar cuando publicaron el parche para las 3 ramas que tienen en producción firmaron los archivos con la clave equivocada, una del ISC ya expirada de 2006, puesto que la persona encargada de firmarlos estaba ausente, para colmo enviaron el anuncio de la liberación de los parches a las listas "bind-users" y "bind-workers" y obviaron "bind-announce", que es donde envían todas las notificaciones sobre actualizaciones y la que posiblemente todos estaban esperando para aplicar los parches a las respectivas distribuciones.


David García
dgarcia@hispasec.com


Más información:

BIND Dynamic Update DoS
https://www.isc.org/node/474

bind9 dies with assertion failure (Debian bugs)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538975

ISC BIND 9 vulnerable to denial of service via dynamic update request
http://www.kb.cert.org/vuls/id/725188

miércoles, 29 de julio de 2009

Microsoft publica dos boletines de seguridad fuera del ciclo habitual

Microsoft ha publicado dos boletines de seguridad fuera de su ciclo habitual de actualizaciones del segundo martes de cada mes. Ambos boletines están relacionados con la Biblioteca de Plantillas Activas de Microsoft, el primero de los boletines afecta a Internet Explorer, mientras que el segundo para Visual Studio está destinado a desarrolladores que hagan uso de dicha librería.

Sin ser el segundo martes de mes, Microsoft acaba de publicar dos boletines de seguridad (con identificadores MS09-034 y MS09-035). Debido a su gravedad, los fallos podrían ser aprovechados por un atacante remoto para ejecutar código arbitrario y comprometer por completo un sistema vulnerable.

La Librería de Plantillas Activas de Microsoft (ATL) es un conjunto de clases de C++ basadas en plantillas que permite crear objetos COM (Component Object Model).

El boletín MS09-034 se refiere a una actualización acumulativa de Internet Explorer que además soluciona tres nuevas vulnerabilidades en ATL (Active Template Library, Librería de Plantillas Activas) que podrían permitir la ejecución remota de código si un usuario visita una página web especialmente manipulada con una versión de Internet Explorer afectada.

El segundo boletín (MS09-035), está destinado a que los desarrolladores que hagan uso de la librería ATL en Visual Studio solucionen las tres vulnerabilidades asociadas. Por eso, su carácter "moderado" y su publicación fuera de ciclo conjunto al anterior boletín descrito. Esta actualización de seguridad está destinada específicamente para desarrolladores de componentes y controles. Los programadores que empleen y distribuyan componentes y controles que usen ATL deben instalar esta actualización y seguir la guía proporcionada para crear y distribuir a sus clientes, componentes y controles que no sean vulnerables a las vulnerabilidades tratadas en el boletín.

Las actualizaciones publicadas pueden descargarse a través de Windows Update o consultando los boletines de Microsoft donde se incluyen las direcciones de descarga directa de cada parche. Dada la gravedad de las vulnerabilidades se recomienda la actualización de los sistemas con la mayor brevedad posible.

La última vez que Microsoft publicó una actualización de seguridad de este tipo, fuera de su ciclo habitual de actualizaciones, fue el 17 de diciembre de 2008, cuando se lanzó el boletín MS08-078 que curiosamente también solucionaba una vulnerabilidad crítica en Internet Explorer.


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Advisory (973882)
Vulnerabilities in Microsoft Active Template Library (ATL) Could Allow Remote Code Execution
http://www.microsoft.com/technet/security/advisory/973882.mspx

Microsoft Security Bulletin MS09-034 - Critical
Cumulative Security Update for Internet Explorer (972260)
http://www.microsoft.com/technet/security/bulletin/MS09-034.mspx

Microsoft Security Bulletin MS09-035 - Moderate
Vulnerabilities in Visual Studio Active Template Library Could Allow Remote Code Execution (969706)
http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx

Microsoft Security Bulletin MS09-032 - Critical
Cumulative Security Update of ActiveX Kill Bits (973346)
http://www.microsoft.com/technet/security/bulletin/ms09-032.mspx

martes, 28 de julio de 2009

Denegación de servicio en la rama 3 de Squid

Se han solucionado varios errores de comprobación de límites y validación de datos de entrada en el control de las cabeceras HTTP de SQUID 3.x. Las vulnerabilidades podrían ser aprovechadas por un atacante remoto para causar una denegación de servicio a través del envió de cabeceras HTTP especialmente manipuladas.

Squid es uno de los más populares servidores proxys usados en la actualidad, en gran parte por ser de código abierto y multiplataforma (aunque sus comienzos fueron para sistemas Unix).

Squid permite autenticación mediante varios protocolos estándar como LDAP, Kerberos, Radius, ... además del control de trafico, puede filtrar tráfico en streaming o chats como Skype, MsnMessenger, YahooMessenger. Permite registrar exhaustivamente las transmisiones y soporta cifrado en TLS, SSL y HTTS entre otras utilidades. Además es compatible con IPv6.

Los problemas están solucionados en las versiones 3.0.STABLE17 y 3.1.0.12, o se puede también aplicar los parches disponibles desde:

Squid 3.0:
http://www.squid-cache.org/Versions/v3/3.0/changesets/b9070.patch
http://www.squid-cache.org/Versions/v3/3.0/changesets/b9074.patch
http://www.squid-cache.org/Versions/v3/3.0/changesets/b9075.patch

Squid 3.1:
http://www.squid-cache.org/Versions/v3/3.1/changesets/b9654.patch
http://www.squid-cache.org/Versions/v3/3.1/changesets/b9661.patch

La rama 2.x no se ve afectada por el problema.


Victor Antonio Torre
vtorre@hispasec.com


Más información:

Squid Proxy Cache Security Update Advisory SQUID-2009:2
http://www.squid-cache.org/Advisories/SQUID-2009_2.txt

lunes, 27 de julio de 2009

Denegación de servicio en Solaris Auditing

Sun ha publicado una actualización para evitar una denegación de servicio local en Solaris Auditing de Solaris 9, 10 y OpenSolaris.

La vulnerabilidad reside en el sistema de auditoría cuando interactúa con archivos con atributos de archivo extendidos y podría ser aprovechada por un usuario local para provocar condiciones de denegación de servicio.

Este problema solo afecta a sistemas con Solaris Auditing activo. Para determinar si un sistema tiene Solaris Auditing habilitado se puede emplear el comando grep para buscar en el archivo "/etc/system" una referencia al módulo c2audit, como en el ejemplo:
$ grep c2audit /etc/system
set c2audit:audit_load = 1

Sun ha publicado las siguientes actualizaciones:

Para plataforma SPARC:
Solaris 9 aplicar parche 122300-39 o superior:
http://sunsolve.sun.com/pdownload.do?target=122300-39&method=h
Solaris 10 aplicar parche 140921-01 o superior:
http://sunsolve.sun.com/pdownload.do?target=140921-01&method=h
OpenSolaris compilación snv_121 o posterior.

Para plataforma x86:
Solaris 9 aplicar parche 122301-39 o superior:
http://sunsolve.sun.com/pdownload.do?target=122301-39&method=h
Solaris 10 aplicar parche 140922-01 o superior:
http://sunsolve.sun.com/pdownload.do?target=140922-01&method=h
OpenSolaris compilación snv_121 o posterior.


Antonio Ropero
antonior@hispasec.com


Más información:

Security Vulnerability in Solaris Auditing Related to Extended File Attributes May Allow Local Unprivileged Users to Panic the System
http://sunsolve.sun.com/search/document.do?assetkey=1-66-264428-1

domingo, 26 de julio de 2009

Mitos y leyendas: El Directorio Activo (IV) (La consola de recuperación)

La consola de recuperación es el siguiente paso que hay que dar en caso de que ninguna opción de inicio pueda solventar un problema. Mediante la consola (a la que casi siempre se tendrá acceso independientemente de la gravedad del problema) es posible activar o desactivar servicios, borrar archivos (en NTFS) y otras muchas acciones administrativas a través de unos pocos comandos muy útiles. Como de costumbre, hay que conocerla antes de que realmente haga falta, e incluso preparar el sistema para poder hacer uso de ella con comodidad cuando sea necesario.

Dos formas de llegar a ella

Existen dos opciones para acceder a esta consola. Una es la que conoce casi todo el mundo: si se dispone del CD de instalación (o desde los antiguos seis disquetes de inicio de Windows 2000), se debe pulsar la tecla R cuando se requiera. La otra fórmula es desde el mismo menú de arranque, pero para esto, antes es necesario que haya sido instalada previamente la consola de recuperación en el disco. Es muy útil en casos de emergencia cuando el CD de arranque o el lector no están operativos o no se tienen a mano.

Para integrar la consola en el sistema, es necesario acceder a la carpeta i386 del CD de instalación y ejecutar

winnt32.exe /cmdcons

Una vez reiniciado el equipo, la consola de recuperación aparecerá como una opción más del menú de arranque (F8) y los CD originales del sistema ya no serán necesarios para acceder a ella. Internamente, lo que se ha hecho es instalar la consola y modificar el archivo boot.ini de Windows.

Comandos

Cuando exista algún problema y sea necesario recurrir a la consola de recuperación, nos pedirá definir el sistema "a recuperar" (aunque haya sólo uno) y se deberá introducir la contraseña de administrador local. Esto puede suponer un problema de seguridad del que hablaremos más abajo.

Un resumen de los comandos más interesantes de la consola de recuperación son:

* BATCH: Permite crear ficheros por lotes, de forma que una secuencia de comandos muy habitual pueda ser ejecutada a través de un simple comando.

* BOOTCFG: Configura boot.ini para añadir instalaciones de Windows. Permite los parámetros: /SCAN (para descubrir las instalaciones de Windows disponibles), /ADD (para agregar una de las instalaciones al menú de inicio), /REBUILD (para reconstruir el menú de inicio a partir de las instalaciones disponibles), /DEFAULT (para definir el arranque predeterminado) y /REDIRECT (permite redirigir la consola a un puerto serie para administrar un servidor sin pantalla ni teclado).

* CHDIR ó CD: funciona como el CD habitual de consola de comandos, pero recordando que para usar directorios con espacios hay que encerrar el nombre entre comillas.

* CHKDSK: comprueba y repara la unidad de disco. Se puede forzar la comprobación con la opción /P.

* ENABLE Y DISABLE: Desactiva un servicio. Es de los comandos más útiles junto con LISTSVC, que muestra el nombre. DISABLE muestra el estado del servicio antes de deshabilitarlo.

* DISKPART: Permite manejar particiones y volúmenes. (Muy útil y desconocido).

* FIXBOOT: reescribe el sector de arranque de la partición indicada.

* FIXMBR: Repara el MBR de un disco físico. Para indicarle cuál, se puede usar MAP, que muestra los discos disponibles, los sistemas de archivo, tamaños y correspondencias con los discos físicos.

* LOGON: Permite presentarse en otras instalaciones de Windows.

* TYPE: Muestra un fichero.

* SET: Muestra o modifica los cuatro valores de entorno: AllowWildCards, AllowAllPaths, AllowRemovableMedia y NoCopyPrompt.

Existen más comandos, que se pueden ver a través de la ayuda HELP. El comando SET Es necesario tener muy en cuenta algunos aspectos antes de lidiar con la consola de recuperación, o su uso nos parecerá muy limitado. En especial con el comando SET, cuyas opciones están a FALSE por defecto.

* AllowWildCards: Si no está activo, la consola no permitirá el uso de comodines tipo *.*.

* AllowAllPaths: Si no está activo, no permitirá que nadie (ni siquiera el administrador) pueda acceder a las carpetas de usuario y otros puntos del sistema. Prácticamente no se podrá acceder a nada que esté fuera del directorio de sistema Windows.

* AllowRemovableMedia: Permite que los ficheros sean copiados a
disquetes, por ejemplo.

* NoCopyPrompt: No pregunta para sobreescribir archivos.

Todas están a FALSE por defecto (desactivadas). Hay que recordar que las opciones AllowRemovableMedia y AllowAllPaths no pueden ser establecidas a TRUE (activadas) si previamente no han sido "autorizadas". Pero no pueden ser autorizadas desde la consola, sino que debe hacerse cuando el sistema todavía es usable. En resumen, el comando SET permite añadir potencia a la consola de recuperación, pero algunas de sus opciones vienen desactivadas por defecto, y es el administrador el que debe decidir si quiere autorizar su uso o no antes de verse obligado a utilizar la consola en sí. Se trata de una medida preventiva de seguridad, para evitar que la consola de recuperación se convierta en un vector de ataque. Es algo que hay que prever antes de hacer uso de la consola o una vez que ocurra un desastre será demasiado tarde.

Autorizando comandos SET

Para poder usar el comando SET, es necesario modificar la directiva de seguridad "Consola de recuperación: permitir la copia de disquetes y el acceso a todas las unidades y carpetas", en las opciones de seguridad de Windows.

La otra directiva "Consola de recuperación: permitir el inicio de sesión administrativo automático" es un problema de seguridad y no debería ser activada. Permite acceder a la consola de recuperación sin necesidad de introducir la contraseña local de administración.

Automatizando el proceso, un ejemplo práctico

Por ejemplo, un sistema no arranca y se determina que puede ser por fallos en los ficheros críticos ntdetect.com y ntldr. Un procedimiento sencillo sería restaurarlos desde el CD a través de la consola de recuperación. Se podría preparar además un disquete o USB con este archivo de texto en él:

Set allowRemovableMedia = True
Set NocopyPrompt = True
Fixboot c:
FixMbr
Chkdsk c:
Attrib -r c:\ntldr
Attrib -r c:\ntdetect.com
Copy d:\i386\ntldr c:\ntldr
Copy d:\i386\ntdetect.com c:\ntdetect.com
Attrib +r c:\ntldr
Attrib +r c:\ntdetect.com

Hay que usar un espacio en cada lado del signo "=". Si no se hace, el comando genera un mensaje de error de "error de sintaxis" y no funciona. Como se observa fácilmente, este lote de comandos intentaría arreglar el sector de arranque, el boot.ini, comprobaría el disco, y modificaría los archivos (siempre quitando antes el permiso de "solo lectura").

Sólo habría que lanzar la consola (bien introduciendo el CD, bien desde el menú de arranque si se ha instalado) y ejecutar una vez en ella:

batch a:\recover.txt

o la unidad donde se encuentre el archivo.


Sergio de los Santos
ssantos@hispasec.com


Más información:

una-al-dia (11/07/2009) Mitos y leyendas: El Directorio Activo (III) (Última configuración buena conocida)
http://www.hispasec.com/unaaldia/3914

una-al-dia (06/07/2009) Mitos y leyendas: El Directorio Activo (II) (Instalación segura)
http://www.hispasec.com/unaaldia/3908

una-al-dia (25/06/2009) Mitos y leyendas: El Directorio Activo (I) (Conceptos)
http://www.hispasec.com/unaaldia/3897

sábado, 25 de julio de 2009

Problema de seguridad en el firmware para routers DD-WRT

Se ha descubierto un error de validación de parámetros de entrada en el interfaz web de DD-WRT v,24. Esto podría ser usado por un atacante remoto sin autenticar para eludir restricciones a través de una URL especialmente manipulada. Este error permite ejecutar comandos del sistema con privilegios de "root".

DD-WRT es un firmware no oficial para routers como Linksys, D-Link y La Fonera, entre otros. Está traducido a más de diez idiomas y es compatible con IPv6, soporta WIFI con distintos tipos de cifrado, permite montar VPN y hasta tiene una versión con VoIP, entre otros tantos servicios típicos de un router.

Este fallo se ha publicado en forma de exploit con todo lujo de detalles (incluso existe un vídeo). El exploit permite lanzar una consola por el puerto 5555 del router.

Por suerte, el interfaz solo está habilitado para la red local salvo que se active para acceder a él de forma remota. La vulnerabilidad ha sido reconocida y ya existe un parche para solucionar este fallo.


Victor Antonio Torre
vtorre@hispasec.com


Más información:

Web oficial de DD-WRT
http://www.dd-wrt.com/dd-wrtv3/index.php

Descarga del parche
http://www.dd-wrt.com/dd-wrtv2/down.php

viernes, 24 de julio de 2009

Adobe conocía su último "0 day" desde 2008

Tras unas horas de rumores Adobe confirmó que una vulnerabilidad en Flash Player estaba siendo aprovechada a través de ficheros PDF con su Adobe Reader. El fallo permitía la ejecución de código arbitrario con solo abrir un archivo PDF o visitar una web con Flash. Como le ocurrió a Microsoft, Adobe conocía el fallo desde 2008, pero no lo había solucionado y los atacantes se le adelantaron para usarlo en su contra. Otro golpe a Adobe.

Un día después de los rumores Adobe confirma la vulnerabilidad como crítica para todas las versiones de sus productos en sistemas Windows, Unix/Linux, Sun y Mac. En el ataque descubierto, el lector PDF llama al reproductor Flash al encontrar ese contenido dentro del documento PDF y es entonces cuando se produce la explotación de la vulnerabilidad. El documento PDF es un medio para llegar al reproductor y en principio no se trataría de una vulnerabilidad transversal, que afecte a varios productos de manera independiente sino que tanto Acrobat como Reader contienen la librería "authplay.dll" (y no autoplay.dll, como por error, indicamos en el correo de la una-al-día anterior) encargada de gestionar con el reproductor el contenido Flash.

El ataque por tanto, se produce aquí a través de archivos PDF con contenido Flash incrustado, aunque nada impide aprovechar el fallo al procesar Flash visitando una web. De hecho al parecer ya se han detectado ataques de este tipo. Cada vez más, puesto que el exploit se ha hecho público, y por tanto el riesgo aumenta considerablemente.

Según Paul Royal de PureWire, Adobe conocía el fallo desde diciembre de 2008, pero no lo había solucionado aún. Estaba en su base de datos de problemas desde casi hace ocho meses. Exactamente igual que le ocurrió a Microsoft con el problema en DirectShow, hasta que el fallo no ha sido descubierto independientemente por atacantes, no ha acelerado el proceso de parcheo. En estos momentos dice que tendrán un parche antes de que acabe julio, pero solo para algunos de sus productos afectados. Para ciertas plataformas, no se sabe cuándo habrá solución.

Un problema añadido en este caso es que JavaScript no es el "disparador" de la vulnerabilidad. Deshabilitarlo en el lector de PDF no protege, como venía siendo habitual. No hay forma sencilla de evitar que se ejecute el contenido Flash en Adobe. Y lo que es peor, aunque no se abran ficheros PDF en los que no se confía, el problema reside en Flash, por tanto con solo navegar con cualquier navegador con Flash instalado, se está en peligro.

La semana pasada, se descubrió que Adobe permitía la descarga de una versión vulnerable de Adobe Reader. Esta semana ha sufrido un problema grave de seguridad en su instalador, que todavía no ha parcheado. Si se suman los continuos problemas de seguridad mal gestionados, los últimos "0 day" en sus productos, y los PDF como vector de ataque preferido del malware, Adobe no pasa por su mejor momento.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Lectores PDF gratutios.
Http://pdfreaders.org

Adobe promises patch for seven-month old Flash flaw
http://www.computerworld.com/s/article/9135826/Adobe_promises_patch_for_seven_month_old_Flash_flaw

jueves, 23 de julio de 2009

Confirmado el 0-day para Adobe Reader, Acrobat y Flash Player

El día 21 se publicó en el blog del PSIRT de Adobe una breve nota en la cual se informaba que estaban investigando una vulnerabilidad en Reader, Acrobat y Flash Player. Symantec habría publicado un breve análisis sobre la explotación de esta vulnerabilidad y un día después Adobe confirma la vulnerabilidad como crítica para las versiones de sus productos afectados en sistemas Windows, Unix y Mac.

El equipo de analistas de Symantec recibió un documento PDF especialmente manipulado para ejecutar código (que ellos identificaron como Pidief.G) que al ser abierto infectaba al equipo con un troyano. Al efectuar el examen del proceso de explotación del lector de Adobe, observaron que la vulnerabilidad no se hallaba donde suponían, en el lector, sino en el reproductor Flash.

El lector PDF llama al reproductor Flash si encuentra contenido en dicho formato dentro del documento PDF y es entonces cuando se produce la explotación de la vulnerabilidad sobre el reproductor Flash. El documento PDF es un medio para llegar al reproductor y en principio no se trataría de una vulnerabilidad transversal, que afecte a varios productos de manera independiente sino que tanto Acrobat como Reader contienen la librería "authplay.dll" encargada de gestionar con el reproductor el contenido Flash.

De hecho incluso la misma vulnerabilidad podría estar siendo explotada a través de una página web con un archivo swf especialmente manipulado.

Adobe recomienda activar el UAC en Windows Vista en particular y, como contramedida, borrar el archivo "authplay.dll" que se encuentra en los directorios de instalación de Reader o Acrobat en sistemas Windows en general.

Según Adobe, el día 30 de julio se dispondrá de una actualización de seguridad de Flash Player para todos los sistemas a excepción de Sun Solaris y el 31 de julio se dispondrá de la correspondiente para Adobe Reader y Acrobat para Windows y Mac y deja pendiente de fecha la publicación de una solución para sistemas UNIX.


David García
dgarcia@hispasec.com



miércoles, 22 de julio de 2009

Cross site scritpting en MediaWiki

Se ha encontrado un fallo de validación de entrada en la función "getContribsLink" del fichero SpecialBlockip.php. Esto podría permitir a un atacante remoto sin privilegios la ejecución de ataques XSS (Cross-Site Scripting) en MediaWiki.

MediaWiki es un proyecto de código abierto que proporciona un motor libre de carácter colaborativo editable por los usuarios, lo que se conoce habitualmente como un wiki. El principal baluarte y ejemplo más representativo de esta plataforma es la enciclopedia libre, la Wikipedia, si bien muchos usuarios emplean MediaWiki para conformar sus propios motores colaborativos.

SpecialBlockip.php se usa para bloquear IPs y usuarios, este script hace una llamada a la función "getContribsLink" sin escapar debidamente las variables de entrada. Esto podría facilitar que un atacante ejecutase código arbitrario HTML y/o script en el contexto de la sesión de navegación del usuario. Esto le permitiría mostrar contenidos ilegítimos en páginas legítimas o acceder a información del usuario.

El problema, de carácter moderadamente crítico, requiere la actualización a las versiones liberadas para tal efecto. El problema afecta a las dos ramas de MediaWiki en funcionamiento, la 1.4.0 y la 1.5.0, con lo que se recomienda a los administradores la actualización con carácter inmediato a las versiones 1.14.1 y 1.15.1, que además solucionan otros fallos. En caso de requerir asistencia, los administradores MediaWiki pueden acudir al soporte comunitario a través de IRC, en el canal #mediawiki de irc.freenode.net


Victor Antonio Torre
vtorre@hispasec.com


Más información:

[MediaWiki-announce] MediaWiki security update: 1.15.1 and 1.14.1
http://lists.wikimedia.org/pipermail/mediawiki-announce/2009-July/000087.html

martes, 21 de julio de 2009

Adobe distribuye una versión vulnerable desde su página oficial

Desde la página oficial de Adobe "Get Reader" los usuarios pueden descargar la última versión 9.1 del lector de PDF. El problema es que esta versión tiene 14 fallos de seguridad. Están solucionados, y existe versión que los corrige, pero Adobe confía (sin advertirlo explícitamente) en que sean los propios usuarios los que, tras la descarga, actualicen manualmente el lector.

Después de la versión 9.1, Adobe publicó la 9.1.1, e incluso más tarde, la 9.1.2 para solucionar graves problemas de seguridad. Pero no las distribuye para usuarios de Mac y Windows. Para usuarios de Linux, sin embargo, sí que se puede descargar directamente la versión 9.1.2. El sistema de actualización de Adobe se ejecuta por defecto una vez a la semana, con lo que, si el usuario no se percata de que acaba de descargar una versión vulnerable, no obtendrá la última actualización hasta una semana más tarde desde su descarga. Este es el escenario más probable, puesto que es lógico pensar que los usuarios concluyan que acaban de descargar la última versión no vulnerable cuando acuden al sitio oficial si no son advertidos de lo contrario. Pero no es así.

Varios usuarios descargaron la última versión de Reader desde el sitio oficial de Adobe, y ejecutaron la herramienta PSI (Personal Security Inspector) de Secunia para comprobar si en su sistema existía algún software vulnerable. Lo que en principio parecía un fallo de detección del programa, ha sido ahora confirmado. Descargaban la versión 9.1 vulnerable.

Un parche o versión corregida que no se ha difundido oficialmente, no es un parche real. Una política mucho más correcta hubiese sido, o bien ofrecer directamente para descarga directa las versiones no vulnerables, o bien obligar, una vez descargado, a ejecutar automáticamente el actualizador durante la instalación, para que los parches sean aplicados. A efectos prácticos, Adobe estaba abriendo deliberadamente una ventana de tiempo en el que permitía que sus clientes se mantuviesen vulnerables a ataques que están siendo aprovechados activamente. Normalmente a través de ficheros PDF especialmente manipulados, y que permiten la ejecución de código en el sistema.

Esta actitud solo sería "permisible" cuando el parche no está convenientemente probado. Esto es, que no introduzca errores de inestabilidad, que solucione todos los vectores por los que una vulnerabilidad puede ser aprovechada, que no exija recompilación, etc. Esto ocurrió, por ejemplo, con la penúltima vulnerabilidad en Firefox. Aunque el problema estaba localizado e incluso existían versiones en desarrollo no vulnerables, Firefox ofreció durante días la versión vulnerable en su página oficial hasta que integró la solución en una nueva versión. Pero cuando el parche está más que aprobado, e incluso ya integrado en nuevas versiones, no hay excusas para retrasar su aplicación.

No se entiende esta política de Adobe, que anda despistado intentando implantar nuevas políticas de seguridad, pero parece que debe todavía aprender mucho al respecto.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Adobe doles out bug-filled PDF Reader to users
http://www.computerworld.com/s/article/9135687/Adobe_doles_out_bug_filled_PDF_Reader_to_users

lunes, 20 de julio de 2009

Symbian firma criptográficamente como válido un troyano

Symbian Foundation ha admitido que un troyano se ha colado en su proceso de validación de software y ha sido firmado criptográficamente para ejecutarse en su sistema operativo, lo que garantiza que proviene de una fuente confiable y que tiene total acceso a los recursos del dispositivo que lo aloje.

El troyano en cuestión se hace llamar "Sexy Space". Craig Heath, jefe de seguridad de Symbian, admitió que este software pasó los controles y fue firmado digitalmente como "garantizado" por la propia Symbian. Symbian sigue el mismo proceso que muchas plataformas hoy en día (iPhone, Wii...): firma criptográficamente cada programa como garantía de que ha pasado unos mínimos controles de procedencia. El problema es que en ese proceso de comprobación de los programas, al parecer se ha colado un troyano y Symbian lo ha firmado como válido para ejecutarse en su sistema operativo. Cabe recordar que las firmas validan siempre la procedencia, (el firmante se hace responsable del contenido) pero la firma no garantiza cómo o qué hace exactamente un programa.

Lo extraño es que esto no haya ocurrido antes, teniendo en cuenta el proceso que sigue una aplicación para ser validada por Symbian. Primero lo analizan con un antivirus automáticamente. Una vez han pasado por esta prueba, solo algunas muestras aleatorias pasan a ser comprobadas por auditores humanos. Lo que ocurrió es que el troyano pasó desapercibido para los motores antivirus (lo que no es ninguna sorpresa) y no tuvo la "suerte" de pertenecer al grupo de programas analizados por auditores.

Symbian Foundation ha revocado la firma de esta pieza, con lo que en teoría, el sistema no permitiría la instalación de nuevas instancias del troyano. El problema es que la funcionalidad de actualizar firmas revocadas no está activa por defecto en Symbian, con lo que esta medida no tendrá mucho impacto.

A raíz de este incidente, Heath piensa que debe mejorar la auditoría "humana" en su proceso de firma. Pero debido al coste, no cree posible que puedan añadirse nuevos recursos en este sentido, sino mejorar los existentes. Interpretando sus palabras, esto puede implicar o bien que los empleados encargados de esta tarea trabajarán más horas, o que mejorar la auditoría "humana" pasa precisamente por automatizar aún más el proceso y que sea menos "humano", lo que llevaría quizás a otro tipo de problemas de seguridad. En cualquier caso Symbian se encuentra ante el mismo problema que las casas antivirus para clasificar malware, pues validar criptográficamente código, no es una tarea muy diferente a la que realizan los motores antivirus a la hora de identificar virus.

Sexy Space se expande por SMS, enviando enlaces a la lista de contactos con contenido pornográficos. Envía datos personales como el IMEI de teléfono a los atacantes, y la víctima deberá hacer frente a los gastos del envío de los mensajes.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Q & A on "Sexy View" SMS worm
http://www.f-secure.com/weblog/archives/00001732.html

Symbian admits Trojan slip-up
http://news.cnet.com/8301-1009_3-10290212-83.html

domingo, 19 de julio de 2009

Problema de seguridad en Android

Se ha descubierto un error de validación a la hora de manejar los permisos encargados de verificar el acceso a la cámara y al audio (Manifest.permission.CAMERA y Manifest.permission.AUDIO_RECORD respectivamente) en Andorid. Esto podría ser aprovechado por un atacante para obtener grabaciones de audio y video sin el consentimiento del usuario.

Cualquier aplicación Android necesitará la confirmación explícita del usuario para acceder a un solo de los recursos de audio y vídeo. Pero si se crea (y el usuario instala) una aplicación que no pida el uso de esos permisos, por error, los tendrá implícitamente (podrá usar el micrófono y la cámara) sin necesidad de que el usuario lo sepa.

Android es un sistema operativo para móviles basado en el kernel de Linux. Inicialmente lo desarrolló Google pero luego ha pasado a pertenecer a la Open Handset Alliance (formada por alrededor de 50 empresas del sector). Android trabaja con dos licencias, GPLv2 para componentes como los parches del kernel y Apache 2 para las aplicaciones ya que permite su comercialización de manera más simple.

Android está pensado para trabajar de manera similar a un Framework que además permite la intercomunicación entre distintas aplicaciones usando un interfaz propio para cada aplicación. El modelo usado por Android permite que los distintos programas informen al resto de que capacidades tienen y así el resto de programas pueden usarlas sin necesidad de implementarlas, claro está siguiendo ciertas reglas de seguridad.
Esta vulnerabilidad evade este control y permite que no se pida autorización al usuario para acceder a la cámara y el audio.

Las APIs oficiales son para Java; no obstante se podrían usar otros lenguajes, pero estos programas deberían compilarse para ARM (el procesador usado en la mayor parte de los dispositivo móviles actuales).

En la actualidad este sistema operativo es usado en algunos modelos de HTC y otras compañías, aunque el numero de dispositivos con este sistema operativo no es muy elevado.

Está solucionado en las versiones Android 1.5 CDBxx, CRCxx y COCxx donde xx son dígitos.


Victor Antonio Torre
vtorre@hispasec.com


Más información:


#2009-011 Android improper camera and audio permission verification
http://www.ocert.org/advisories/ocert-2009-011.html

sábado, 18 de julio de 2009

Boletines de seguridad de Microsoft en julio

Este pasado martes Microsoft publicó seis boletines de seguridad (del MS09-028 al MS09-033) correspondientes a su ciclo habitual de actualizaciones. Según la propia clasificación de Microsoft tres de los boletines presentan un nivel de gravedad "crítico" y los tres restantes son "importantes".

Los boletines "críticos" son:

* MS09-028: Actualización para corregir tres vulnerabilidades en Microsoft DirectShow, que podrían permitir la ejecución remota de código si el usuario abre un archivo QuickTime específicamente creado. Afecta a Windows XP, 2000 y Server 2003.

* MS09-021: Actualización destinada a corregir tres vulnerabilidades en el interprete de las fuentes EOT (Embedded OpenType), que podrían permitir la ejecución remota de código arbitrario. Afecta a Windows XP, 2000, Vista, Server 2003 y Server 2008.

* MS09-032: Actualización de seguridad de los kill bits de ActiveX en Microsoft Windows, que podría permitir la ejecución remota de código arbitrario. Afecta a Windows XP, 2000, Vista, Server 2003 y Server 2008.

Los boletines clasificados como "importantes" son:

* MS09-030: Actualización destinada a solucionar una vulnerabilidad en Microsoft Office Publisher, que podría permitir la ejecución remota de código si un usuario si un usuario abre un archivo de Publisher específicamente creado.

* MS09-031: En este boletín se ofrece una actualización para resolver
Una vulnerabilidad en Microsoft Internet Security and Acceleration (ISA) Server 2006 que podría ser aprovechada por un atacante para conseguir elevar sus privilegios en los sistemas afectados.

* MS09-033: En este boletín se corrige una vulnerabilidad en Microsoft Virtual PC y Microsoft Virtual Server que podría ser aprovechada por un atacante para conseguir elevar sus privilegios en los sistemas afectados.

Las actualizaciones publicadas pueden descargarse a través de Windows Update o consultando los boletines de Microsoft donde se incluyen las direcciones de descarga directa de cada parche. Dada la gravedad de las vulnerabilidades se recomienda la actualización de los sistemas con la mayor brevedad posible.


Antonio Ropero
antonior@hispasec.com


Más información:

Microsoft Security Bulletin Summary for July 2009 http://www.microsoft.com/technet/security/bulletin/ms09-jul.mspx

Microsoft Security Bulletin MS09-028 - Critical
Vulnerabilities in Microsoft DirectShow Could Allow Remote Code Execution (971633)
http://www.microsoft.com/technet/security/bulletin/MS09-028.mspx

Microsoft Security Bulletin MS09-029 - Critical
Vulnerabilities in the Embedded OpenType Font Engine Could Allow Remote Code Execution (961371)
http://www.microsoft.com/technet/security/bulletin/MS09-029.mspx

Microsoft Security Bulletin MS09-032 - Critical
Cumulative Security Update of ActiveX Kill Bits (973346)
http://www.microsoft.com/technet/security/bulletin/ms09-032.mspx

Microsoft Security Bulletin MS09-030 - Important
Vulnerability in Microsoft Office Publisher Could Allow Remote Code Execution (969516)
http://www.microsoft.com/technet/security/bulletin/ms09-030.mspx

Microsoft Security Bulletin MS09-031
Vulnerability in Microsoft ISA Server 2006 Could Cause Elevation of Privilege (970953) - Important
http://www.microsoft.com/technet/security/bulletin/ms09-031.mspx

Microsoft Security Bulletin MS09-033
Vulnerability in Virtual PC and Virtual Server Could Allow Elevation of Privilege (969856)
http://www.microsoft.com/technet/security/bulletin/ms09-033.mspx

viernes, 17 de julio de 2009

Mozilla publica parche oficial para la vulnerabilidad en Firefox 3.5

Mozilla ha publicado ya oficialmente la versión 3.5.1 que corrige el fallo en JIT que permitía la ejecución de código. El exploit fue publicado por sorpresa, cuando el equipo de desarrollo todavía no disponía de una versión corregida que ofrecer a los usuarios. Pensaban publicar la actualización a finales de julio, pero han acelerado convenientemente el proceso para emitir la nueva versión lo antes posible.

¿Pero no existía parche ya?

A raíz de la cantidad de comentarios recibidos en nuestros buzones, sobre la información publicada en la una-al-día "Ejecución de código en Mozilla Firefox. No existe parche oficial disponible", creemos necesario aclarar ciertos puntos y actualizar la información existente.

El comentario más repetido es que "sí" existía parche en el momento de la publicación de la noticia. Queremos aclarar y ratificarnos en que no existía, hasta este momento, parche oficial disponible, aclarando correctamente lo que es un parche oficial. Entendemos como "parche oficial", un método de actualización que no exija "recompilación" del software, ofrecido por el fabricante, y que haya pasado unos mínimos controles para comprobar que no introduce nuevos errores. El mismo blog de seguridad oficial de Mozilla (http://blog.mozilla.com/security/), escribía:

Status: "Mozilla developers are working on a fix for this issue and a Firefox security update will be sent out as soon as the fix is completed and tested."

Estaban trabajando en una solución. En cuanto han creído que el parche es correcto, no abre nuevos fallos y está concienzudamente comprobado, han subido a la página oficial la versión 3.5.1 para que todo el mundo pueda descargarla. La política de Firefox en este sentido es crear nuevas versiones con la solución integrada. Desde el día 13 (cuando ya se conocía el fallo) y hasta ahora, solo estaba disponible para descarga oficial la versión 3.5, vulnerable. No había parche oficial comprobado, si no, obviamente Mozilla lo habría subido como descarga pública oficial.

¿Qué tenían entonces antes de la versión 3.5.1?

Tenían la localización del problema, y un planteamiento de modificación del código para solucionar el fallo (que probablemente fuese el definitivo), en forma de archivo .diff o precompilaciones diarias inestables o versiones de desarrollo. Pero eso no es un parche oficial. Cuando existe un fallo de seguridad, y más cuando se tiene delante un exploit, la parte más "sencilla" es localizar la línea que origina el problema y programar una solución. Esto es prácticamente inmediato sea software libre o no. Lo complicado es integrar esto en una versión oficial que sea compilada y distribuida públicamente, asegurándose de que no introduce regresiones, problemas de estabilidad y que de verdad soluciona todos los vectores por los que la vulnerabilidad puede ser aprovechada. Solo este último punto puede llevar semanas. Si no se respeta este paso, se corre el riesgo de emitir constantes versiones con regresiones (un problema más común de lo que parece) e introducir inestabilidades.

En un entorno no profesional, casero, es viable aplicar un parche en forma de archivo .diff, compilar extraoficialmente y asumir los problemas potenciales que esto puede acarrear. Pero en entornos profesionales, con decenas o cientos de máquinas que administrar, no es tan sencillo. Todo debe seguir funcionando, y nadie que se tome en serio su negocio usaría versiones no estables, en desarrollo o compilaciones diarias en entornos de producción más o menos críticos. En entornos más exigentes, incluso no aplican nunca los parches oficiales nada más son publicados, sino que son todavía más cautelosos y esperan a comprobar que no introducen nuevos problemas.

También cabe recodar, que deshabilitar el origen del problema no es "solucionar" la vulnerabilidad.

Con respecto a la vulnerabilidad, aclaramos que el fallo se encuentra en en el compilador Just-in-time (JIT). La rama 3.0.x no se ve afectada.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Critical JavaScript vulnerability in Firefox 3.5
http://blog.mozilla.com/security/2009/07/14/critical-javascript-vulnerability-in-firefox-35

jueves, 16 de julio de 2009

Grupo de parches de julio para diversos productos Oracle

Oracle ha publicado un conjunto de 33 parches para diversos productos de la casa que solventan una larga lista de vulnerabilidades sobre las que apenas han dado detalles concretos. Las consecuencias son que atacantes locales y remotos pueden provocar denegaciones de servicio, ejecutar código arbitrario, tener acceso de escritura y lectura a datos sensibles, perpetrar ataques de inyección SQL y eludir restricciones de seguridad.

Los fallos se dan en varios componentes de los productos:
* Oracle Database 11g, versión 11.1.0.6, 11.1.0.7
* Oracle Database 10g Release 2, versiones 10.2.0.3, 10.2.0.4
* Oracle Database 10g, versión 10.1.0.5
* Oracle Database 9i Release 2, versiones 9.2.0.8, 9.2.0.8DV
* Oracle Application Server 10g Release 2 (10.1.2), versión 10.1.2.3.0
* Oracle Application Server 10g Release 3 (10.1.3), versiones 10.1.3.3.0, 10.1.3.4.0
* Oracle Identity Management 10g, versión 10.1.4.0.1, 10.1.4.2.0, 10.1.4.3.0
* Oracle E-Business Suite Release 12, versión 12.1
* Oracle E-Business Suite Release 12, versión 12.0.6
* Oracle E-Business Suite Release 11i, versión 11.5.10.2
* Oracle Enterprise Manager Database Control 11, versión 11.1.0.6, 11.1.0.7
* Oracle Enterprise Manager Grid Control 10g Release 4, versión 10.2.0.4
* PeopleSoft Enterprise PeopleTools versiones: 8.49
* PeopleSoft Enterprise HRMS versiones: 8.9 y 9.0
* Siebel Highly Interactive Client versiones: 7.5.3, 7.7.2, 7.8, 8.0, 8.1
* Oracle WebLogic Server 10.3, 10.0MP1
* Oracle WebLogic Server 9.0 GA, 9.1 GA, 9.2 hasta 9.2 MP3
* Oracle WebLogic Server 8.1 hasta 8.1 SP6
* Oracle WebLogic Server 7.0 hasta 7.0 SP7
* Oracle Complex Event Processing 10.3 y WebLogic Event Server 2.0
* Oracle JRockit R27.6.3 y anteriores (JDK/JRE 6, 5, 1.4.2)

De las 33 correcciones:

* 10 afectan a Oracle Database. Tres de las cuales no requieren un usuario y contraseña válidos para poder ser aprovechadas. Ninguna es aplicable a las instalaciones de cliente. 2 afectan a Oracle Secure Backup. Una de las cuales no requieren un usuario y contraseña válidos para poder ser aprovechadas. Los componentes afectados son: Network Foundation, Network Authentication, Advanced Replication, Config Management, Upgrade, Virtual Private Database, Listener, Secure Enterprise Search, Core RDBMS y Auditing.

* Dos vulnerabilidades para Oracle Secure Enterprise Search 10g con Oracle Secure Enterprise Search.

* Dos afectan a Oracle Application Server. Las dos requieren un usuario y contraseña válidos para poder ser aprovechadas. Ninguna es aplicable a las instalaciones de cliente. Los componentes afectados son: Oracle Security Developer Tools y HTTP Server.

* 5 afectan a Oracle Applications. 3 no requieren un usuario y contraseña válidos para poder ser aprovechadas. Los componentes afectados son: Oracle Application Object Library, Application Install, Oracle Applications Framework, Oracle iStore y Oracle Applications Manager.

* Dos afectan a Oracle Enterprise Manager. Todas requieren un usuario y contraseña válidos para poder ser aprovechadas. Los componentes afectados son: Config Management.

* Tres afectan a Oracle PeopleSoft and JDEdwards Suite. Una no requiere un usuario y contraseña válidos para poder ser aprovechada. Los componentes afectados son: PeopleSoft Enterprise FMS, PeopleSoft Enterprise PeopleTools - Enterprise Portal y PeopleSoft Enterprise HRMS eProfile Manager.

* Una afecta a Oracle Siebel Suite. Requiere un usuario y contraseña válidos para poder ser aprovechada. Los componentes afectados son: Highly Interactive Client

* Cinco afectan a Oracle BEA Products Suite. Ninguna requiere un usuario y contraseña válidos para poder ser aprovechada. Los componentes afectados son: Jrockit, Oracle Complex Event Processing, WebLogic Server.

Para comprobar las matrices de productos afectados, gravedad y la disponibilidad de parches, es necesario comprobar la notificación oficial:

Oracle Critical Patch Update Advisory - July 2009
http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujul2009.html


Sergio de los Santos
ssantos@hispasec.com


Más información:

Oracle Critical Patch Update Advisory - July 2009
http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpujul2009.html

miércoles, 15 de julio de 2009

Ejecución de código en Mozilla Firefox. No existe parche oficial disponible

Ofrecemos este boletín con carácter de urgencia. Se ha publicado un exploit para Mozila Firefox 3.5 que permite la ejecución de código si un usuario visita una página web especialmente manipulada. No existe parche oficial disponible.

Un tal Simon Berry-Byrne ha descubierto un problema de seguridad en Firefox que podría ser aprovechado por atacantes para ejecutar código arbitrario con los privilegios bajo los que se ejecuta el navegador. Existe exploit público disponible, con lo que es posible que los atacantes comiencen, en breve, a explotar el fallo para la instalación de malware, y "aprovechar" así la creciente cuota de mercado de usuarios de Firefox.

El exploit ha sido publicado sin previo aviso, con todo lujo de detalles y listo para ser usado en entornos Windows. Aunque no es necesario una excesiva modificación para que pueda ejecutarse código en cualquier otra plataforma. El fallo en concreto se da en (cómo no) el procesador de código JavaScript del navegador a la hora de manejar ciertas etiquetas ("font", entre ellas) HTML.

No se tiene constancia de que los atacantes estén aprovechando este fallo, por lo que no se podría hablar estrictamente de "0 day", aunque a partir de ahora el problema es grave, puesto que el código para su explotación es público.

Se recomienda desactivar JavaScript en Firefox o el uso de navegadores alternativos (no Internet Explorer puesto que en estos momentos también sufre de varios problemas de seguridad no resueltos).


Sergio de los Santos
ssantos@hispasec.com


Más información:

Firefox 3.5 Vulnerability
http://milw0rm.com/exploits/9137

martes, 14 de julio de 2009

Otro "0 day" en Microsoft... a través de Microsoft Office Web Component

Por sorpresa, Microsoft ha publicado que se están detectando ataques contra Microsoft Office Web Components a través de Internet Explorer que permiten la ejecución de código. Este es el tercer "0 day" de Microsoft (todos con ActiveX) en mes y medio.

Microsoft Office Web Components es una colección de controles COMs (Component Object Model) que se usa para publicar contenido de Office en en la web a través de Internet Explorer. En pocas palabras, un ActiveX. En él, existe un fallo que permite a un atacante ejecutar código arbitrario si la víctima visita una web especialmente manipulada. El software afectado es el siguiente:

* Microsoft Office XP Service Pack 3
* Microsoft Office 2003 Service Pack 3
* Microsoft Office XP Web Components Service Pack 3
* Microsoft Office 2003 Web Components Service Pack 3
* Microsoft Office 2003 Web Components para Microsoft Office 2007 Service Pack 1
* Microsoft ISA Server 2004 Standard Edition Service Pack 3
* Microsoft I ISA Server 2004 Enterprise Edition Service Pack 3
* Microsoft ISA Server 2006
* ISA Server 2006 Supportability Update
* Microsoft ISA Server 2006 Service Pack 1
* Microsoft Office Small Business Accounting 2006

Con esto, Microsoft acumula tres "0 day" sin solución. Se supone que hoy, en su ciclo habitual de actualizaciones, al menos solucionará uno de ellos. No se recordaba una actividad parecida desde el verano de 2006. Entonces, los atacantes se cebaron en Office. En aquel momento se popularizaron las amenazas directas y personalizadas contra compañías que recibían este intento de infección. Se trataba de ataques perpetrados especialmente contra ellos. Se descubrieron una media de dos vulnerabilidades por mes durante julio y agosto en Word, Excel o PowerPoint. Además, se detectaron siempre los ataques muy poco tiempo después del segundo martes de cada mes, con lo que normalmente fue necesario esperar casi todo un mes para que Microsoft cumpliese su siguiente ciclo de actualizaciones y poder estar protegido. Se observó entonces un claro cambio de tendencia en la forma en la que aparecieron estos problemas, unida a una obsesiva y oportunista fijación contra este software de Microsoft.

Para mitigar el problema en Microsoft Office Web Component se recomienda activar el kill bit del control ActiveX para evitar que sea llamado por Internet Explorer. Es posible hacerlo guardando este archivo con extensión .reg y ejecutarlo como administrador:



Windows Registry Editor Version 5.00



[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{0002E541-0000-0000-C000-000000000046}]

"Compatibility Flags"=dword:00000400

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{0002E559-0000-0000-C000-000000000046}]

"Compatibility Flags"=dword:00000400





Sergio de los Santos
ssantos@hispasec.com


Más información:

Vulnerability in Microsoft Office Web Components Control Could Allow Remote Code Execution
http://www.microsoft.com/technet/security/advisory/973472.mspx?pubDate=2009-07-13

lunes, 13 de julio de 2009

Denegación de servicio a través de mod_deflate en Apache 2.x

Se ha anunciado una vulnerabilidad en mod_deflate de Apache, por la que un atacante remoto podría provocar condiciones de denegación de servicio.

El módulo mod_deflate permite comprimir la salida de apache filtrando por tipos de ficheros, y así disminuir el trafico en la red. Aunque se instala por defecto en el paquete de apache, no viene activado por defecto.

El problema reside en que el módulo mod_deflate continúa comprimiendo ficheros grandes después de que la conexión de red haya sido cerrada. Un atacante remoto podría enviar datos especialmente manipulados y hacer que el servicio consumiese todos los recursos de CPU por un periodo limitado de tiempo.

Se ha publicado una actualización en forma de código fuente, disponible en:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/server/core_filters.c?r1=421103&r2=791454&pathrev=791454&view=patch


Laboratorio Hispasec
laboratorio@hispasec.com


Más información:

mod_deflate DoS
http://marc.info/?l=apache-httpd-dev&m=124621326524824&w=2

apache2.2-common: DOS possible with mod_deflate
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534712

domingo, 12 de julio de 2009

Symantec y la confianza en antivirus gratuitos

David Hall, jefe de producto de Symantec, ha realizado declaraciones en contra de las soluciones antivirus gratuitas. "No son suficientes para mantener al usuario seguro". Si bien lleva razón en que los antivirus por sí solos no son suficientes para asegurar a nadie, no es relevante el hecho de que sean gratuitos o no. La declaración viene después de que Microsoft lance su propio antivirus gratuito Security Essentials.

Según este ejecutivo de Symantec, los antivirus gratuitos no pueden mantener el nivel de las suites como las que ofrece Symantec. "Si hoy en día sólo confías en antivirus gratuitos para protegerte, no estás obteniendo la protección que necesitas para mantenerte limpio y evitar el robo de identidad". "Microsoft Security Essentials es una versión 'incompleta' de OneCare [producto de pago de Microsoft]... y los usuarios no necesitan 'menos' protección, necesitan 'más'".

Obviamente el comentario proviene de alguien cuya misión es elevar las ventas de su producto Symantec, pero no es oportuno desprestigiar tecnología ajena para conseguirlo. Hall también reconoce lo obvio: "los antivirus deberían ser considerados la última defensa" pero de sus opiniones sobre los productos "gratuitos" (que considera versiones inferiores), se puede concluir que un usuario, por el hecho de haber comprado un antivirus, está más y mejor protegido.

¿Qué diferencia hay entre un antivirus gratuito y uno de pago?

Existen diferencias además de en el precio, pero no suelen estar en el motor antivirus. La mayoría de los motores (tecnología de detección y base de firmas) son compartidos entre las versiones gratuitas y las de pago. Lo que suelen añadir las versiones de pago son capas adicionales de protección, que pueden ser más o menos útiles para el usuario. Si nos restringimos a la detección por motores, hoy en día, el usuario corre el mismo riesgo de infección con un producto de pago que con uno gratuito. En este sentido, los antivirus han perdido la batalla ante el malware, todos por igual. Una tecnología de detección más cara no la hace necesariamente mejor. Se paga por servicios adicionales añadidos al motor antivirus.

El mensaje, o el titular que puede extraerse de las declaraciones de Hall por tanto es erróneo (sobre todo el desafortunado "usar antivirus gratuitos es peligroso"). Los antivirus gratuitos no son necesariamente peor que los de pago, a nivel de detección. Este matiz es muy importante. A mediados de esta década, cuando el problema del malware fue patente, las casas antivirus accedieron a añadir nuevas capas de protección en sus productos: cortafuegos, análisis de comportamiento, antiphishing, antirootkit, protección de identidad, antispam... Un producto de pago ofrece más capas de protección, y esto sin duda más beneficioso para el usuario. Como los antivirus gratuitos suelen prescindir de estas capas y centrarse en el "antivirus", el razonamiento de Hall es que los antivirus gratuitos no son lo que necesita un usuario. No hay que olvidar tampoco, que los antivirus gratuitos no suelen ofrecer soporte.

¿Qué necesita entonces un usuario?

El caso es que en parte Hall lleva razón. El antivirus es necesario, pero no lo más importante hoy en día para evitar el malware, y por eso las capas adicionales son necesarias. Pero la detección de los antivirus gratuitos es igual de pobre que la de los de pago. El hecho de añadir tecnología de protección adicional, como cortafuegos, antispam, etc, en forma de suites de pago, mejora la seguridad, y es el usuario el que debe decidir qué necesita y si está dispuesto a pagar por esa protección extra. Por supuesto, siempre teniendo en cuenta que ninguna tecnología protege al usuario por completo: al igual que con la detección, también los antivirus tienen serios y numerosos problemas para reconocer las conexiones salientes no legítimas (en sus cortafuegos), para clasificar el spam (en sus sistemas antispam), para catalogar el phishing (en sus sistemas antiphishing) y para ofrecer ayuda útil y real a un usuario (en sus “call centers” de soporte). El problema del malware supera a todos en todos los aspectos.

Además, Hall también dice que las casas antivirus que ofrecen productos gratuitos no poseen los recursos para lidiar con las amenazas de seguridad. Esto es incompleto. Las casas antivirus con productos exclusivamente de pago tampoco disponen de esos recursos hoy en día. Nadie los tiene.

Conclusión

En definitiva, la realidad es que si un usuario necesita un antivirus (y solo un antivirus) puede optar por las soluciones gratuitas porque son igual de efectivas que el resto. Siempre podrá complementarla con otros productos específicos de otros fabricantes que completen su seguridad. Si quiere una suite integrada con soporte, sin duda la elección está en los productos de pago, y en ellos encontrará un excelente escudo contra muchas amenazas. Pero siempre deberá tener en cuenta que los antivirus no son la solución definitiva. Hoy en día los consejos contra el malware, por orden de importancia, podrían ser:

* No usar Windows como administrador.
* Actualizar con los parches de seguridad, tanto de programas como del sistema operativo.
* Mantenerse informado.

Y sí, también un antivirus, un antispam, una barra antiphishing, un antirootkit... gratuitos o no.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Symantec: it’s dangerous to rely on free antivirus
http://tech.blorge.com/Structure:%20/2009/07/04/symantec-its-dangerous-to-rely-on-free-antivirus/

sábado, 11 de julio de 2009

Mitos y leyendas: El Directorio Activo (III) (Última configuración buena conocida)

Cuando un controlador de dominio (o Windows en general) falla, existen algunos pasos que el administrador puede seguir para solucionar el problema, sin necesidad de recurrir a métodos drásticos como la reinstalación (algo poco viable en Directorios Activos en producción). Conocer a fondo para qué sirven los métodos de recuperación y cuáles son los que tenemos en nuestra mano, es esencial. Hoy hablaremos de la "Última configuración buena conocida", sobre la que no se suele saber mucho, o se usa de forma incorrecta.

Cuestión de drivers

Hay que entender que la "Última configuración buena conocida" está limitada prácticamente al entorno de los controladores, servicios y perfiles hardware. Windows almacena en el registro información de los controladores instalados, y mantiene copias de diferentes estados para volver a ellos en caso de error. Esto es esencial porque los controladores son la mayor parte de las veces, los culpables de los "pantallazos azules" o BSOD (Blue screen of death). Los drivers se mueven en una zona de memoria distinta a la de los usuarios (en un anillo diferente). El kernel y los drivers de sistema, están en el Ring0, el modo de ejecución de mayor privilegio para poder trabajar a bajo nivel con el hardware. Trabajar a tan bajo nivel implica que se tiene total control sobre la máquina y por tanto, una mayor responsabilidad (un fallo da al traste con todo el sistema operativo). El Ring3 un espacio en el que un fallo no resultaría tan crítico, porque no pueden acceder al hardware directamente, deben hacerlo a través de llamadas a sistema. MS-DOS, por ejemplo, carecía de este concepto. Todo corría bajo privilegios de Ring0, de ahí la inestabilidad general del sistema operativo ante cualquier fallo de cualquier programa.

¡No inicies sesión!

Para Windows, una configuración buena conocida es la última en el que el usuario ha conseguido abrir una sesión en ella, independientemente de los errores producidos durante el arranque. Está diseñada para permitir la recuperación ante un problema de controladores en el registro desde la última vez que se arranca Windows. Hay que tener en cuenta (al contrario de lo que muchos piensan) que con este método el sistema no se podrá recuperar de un fallo en la lectura por ejemplo de archivos esenciales del sistema operativo. "Última configuración buena conocida" no es una copia del sistema anterior, sino un recordatorio del conjunto de controladores que han funcionado correctamente en la última autenticación del usuario.

De hecho, el mensaje "error durante el inicio del sistema en al menos un servicio o controlador" que aparece en ocasiones antes de abrir una sesión o justo después de reiniciar tras la instalación de un controlador o algún cambio importante, sirve para alertar al usuario de que no debe iniciar sesión. Si el usuario es precavido y no inicia sesión, podrá reiniciar entonces en modo "Última configuración buena conocida" y los cambios volverán a cuando se presentó en el sistema la última vez (antes de instalar ese controlador que ha dado problemas). Si aparece pues este error antes de presentarnos en el sistema, es importante reiniciar sin llegar a abrir sesión para poder volver realmente a la "Última configuración buena conocida". Se aconseja por tanto, usar la "Última configuración buena conocida" antes que cualquier otra opción que pueda hacer que se sobrescriba esta configuración. No es necesario preocuparse por presentarse en el modo seguro del sistema, pues arrancar de esta forma no actualiza la configuración de la "Última configuración buena conocida". Por tanto, si no se ha podido resolver el problema a través del modo seguro, todavía sería posible usar esta opción.

Windows XP permite también seleccionar la "Última configuración buena conocida" cuando detecta que el último arranque del sistema no ha sido correcto. En este caso muestra un menú de forma automática (distinto al que se consigue presionando F8 durante el arranque) que incluye la posibilidad de utilizar la última configuración buena conocida.

Cómo funciona

Internamente, Windows administra varios juegos de configuraciones del sistema (habitualmente dos). Normalmente inicia con la configuración predeterminada que aloja la rama del registro HKLM\System\CurrentControlSet, que es un puntero al control que ha sido usado para arrancar (ControtSet001, ControlSet002, ControlSet003...). O sea, la información real es solo la que está en ControtSet00X, el resto son punteros.

Windows no actualiza esta información en el registro hasta que el sistema se inicia correctamente y alguien se autentica (se presenta) en él, asegurándose de esta forma que la información almacenada como "buena conocida" permite al menos que un usuario se presente. Esto lo hace ayudándose de una rama del registro oculta llamada "Clone". El registro juega con una serie de punteros (explicados más abajo) que van cambiando su valor, apuntando siempre a estos distintos ControlSet. La rama "Clone", representa una especie de variable temporal entre la configuración actual y la última buena conocida, para que no se sobrescriban entre ellas.

Punteros a configuraciones

La clave HKEY_LOCAL_MACHINE\SYSTEM\Select mantiene a su vez cuatro valores en su rama y almacena la información necesaria para que Windows organice los perfiles y sepa qué configuración es la última buena conocida. Son punteros que pueden establecerse a valores como 0, 1 ó 2 para indicar a qué ControlSet se refieren

* HKEY_LOCAL_MACHINE\SYSTEM\Select\Current: Indica qué ControlSet, ControlSet001 o ControlSet002 ha sido con el que se ha iniciado el sistema en esta sesión en concreto.

* HKEY_LOCAL_MACHINE\SYSTEM\Select\Default indica qué ControlSet es el perfil por defecto usado para arrancar la máquina. (Suele ser el ControlSet001)

* HKEY_LOCAL_MACHINE\SYSTEM\Select\Failed indica qué perfil de control ha fallado por última vez al intentar arrancar.

* HKEY_LOCAL_MACHINE\SYSTEM\Select\LaskKnownGood indica qué ControlSet será el conjunto tomado para arrancar si se elige "Última configuración buena conocida" durante el arranque.


Sergio de los Santos
ssantos@hispasec.com



viernes, 10 de julio de 2009

Microsoft publicará seis boletines de seguridad el próximo martes

En su ciclo habitual de actualizaciones los segundos martes de cada mes, Microsoft ha anunciado que en esta ocasión se esperan seis boletines de seguridad. Tres de las actualizaciones afectan a Windows en general, una a Publisher, una a ISA Server y otra Virtual PC (Server). Parece que corregirá los dos "0 days" activos que mantiene.

Si en junio se publicaron doce boletines que parchearon hasta 31 vulnerabilidades diferentes, este mes Microsoft prevé publicar seis actualizaciones el martes 14 de julio. Tres boletines son críticos, y el resto importantes. De los tres boletines dedicados a Windows, las versiones de XP se llevan la peor parte, pues se ven afectados por todos. Vista y 2008, sin embargo, solo se ven afectados por uno de estos boletines.

Adicionalmente, y como viene siendo habitual, Microsoft publicará una actualización para Microsoft Windows Malicious Software Removal Tool. Además, se publicarán actualizaciones de alta prioridad no relacionadas con la seguridad.

La buena noticia es que en que se confirma que en esta tanda se solucionará la vulnerabilidad CVE-2009-1537, un problema de ejecución de código en DirectShow que Microsoft reconoció a finales de mayo. Sobre la otra vulnerabilidad que está siendo aprovechada por atacantes, CVE-2008-0015 ("0 day" destapado hace unos días) Microsoft dice que "nuestros ingenieros han trabajado las 24 horas del día para producir una actualización" y "creen que estará lista con la calidad apropiada" para el martes. Teniendo en cuenta que conocían la vulnerabilidad desde la primavera de 2008, da la impresión de que realmente han realizado en unos días (desde que se hizo pública) el esfuerzo de todo un año.

Microsoft ha reconocido que mientras "estudiaba a fondo" la vulnerabilidad, los atacantes lo descubrieron de forma paralela y comenzaron a explotarla. Son los riesgos de investigar durante más de un año la solución de un desbordamiento de memoria intermedia sin que interfiera en otros elementos del sistema operativo. Es demasiado tiempo, una ventana de riesgo excesivamente amplia. Existen investigadores a tiempo completo, dedicados a la creación de malware, que descubrirán el fallo tarde o temprano. Cuanto más tiempo pase, más posibilidades de que lo hagan. ¿Cuántas vulnerabilidades están siendo aprovechadas sin que lo detectemos mientras estudian una solución? Este problema puede ocurrir con cualquier pieza de software, pero con este incidente Microsoft ha dado a entender que mientras no salten a la luz, la espera puede alargarse considerablemente y no se sienten tan presionados como para solucionarlos lo antes posible, o no les imprimen la prioridad que los problemas se merecen. Si la excusa para el letargo es que "existen otros problemas de seguridad más urgentes que atender", el consuelo es mínimo.

Los parches anunciados están sujetos a cambios, en cualquier caso, con lo que no se garantiza que no se produzcan cambios de última hora.

Hispasec Sistemas publicará puntualmente a través de este boletín información detallada sobre los nuevos parches.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Microsoft conocía el último "0 day" desde 2008
http://www.hispasec.com/unaaldia/3911/microsoft-conocia-ultimo-day-desde

0 day en la librería msvidctl.dll de Microsoft Windows
http://www.hispasec.com/unaaldia/3907/day-libreria-msvidctldll-microsoft-windows

jueves, 9 de julio de 2009

Microsoft conocía el último "0 day" desde 2008

El pasado día 4 de julio se supo que ciertos atacantes estaban aprovechando de forma masiva una vulnerabilidad no hecha pública hasta ahora en un ActiveX de Microsoft. Poco después Microsoft confirmaba el problema en una notificación, que ofrecía contramedidas pero en el que todavía no se publicaba parche oficial. Al parecer, Microsoft estaba al tanto desde 2008 no solo de esta, sino de otra vulnerabilidad más en el mismo componente.

CVE-2008-0015 es el CVE que Microsoft ha asignado a este nuevo "0 day". El CVE es el Common Vulnerabilities and Exposures, un estándar (administrado por la organización Mitre.org) que se encarga de identificar unívocamente a las vulnerabilidades. El CVE ha tenido gran aceptación entre todos los fabricantes porque la mayor parte de las veces es muy complejo saber a qué vulnerabilidad nos estamos refiriendo solo por ciertas características. Es necesario una especie de número de identidad único para cada fallo, puesto que en ocasiones son tan parecidas, complejas o se ha ofrecido tan poca información sobre ellas que la única forma de diferenciar las vulnerabilidad es por su CVE.

¿Por qué asignar un CVE de 2008 en 2009? Esto significa que Microsoft conocía el fallo desde el año pasado. Los fabricantes solicitan CVEs al Mitre y los asignan libremente a las vulnerabilidades que encuentran. Ryan Smith y Alex Wheeler de IBM ISS X-Force lo descubrieron y lo reportaron entonces. Microsoft asignó el CVE pero todavía no lo ha hecho público ni lo ha solucionado... hasta que se ha convertido en un "0 day". Los atacantes (no se sabe cómo) han descubierto la existencia del fallo y desde no se sabe cuándo, están aprovechándolo para instalar malware en los sistemas Windows. Esto ha hecho que Microsoft deje de mantener la vulnerabilidad en el letargo y tenga que ponerse a trabajar en ella cuanto antes.

¿Es normal tardar tanto para solucionar una vulnerabilidad? Según Microsoft, básicamente depende de si es conocida o no. La compañía se vuelca totalmente en un fallo cuando es público, si no, va a "otro ritmo" a la hora de parchear. Incluso cuando la vulnerabilidad es pública, hay que tener en cuenta que Microsoft hace insistentes pruebas de compatibilidad cada vez que saca un parche, y aun así, a veces comete errores. El código del sistema operativo es demasiado complejo y las interacciones pueden ser impredecibles, así que la estrategia para los parches de Windows es "lento pero (en lo posible) seguro". En este caso Microsoft ha sido lento sin excusas, teniendo en cuenta la gravedad de la vulnerabilidad, el tiempo transcurrido y que (como ha pasado) al final la información o bien ha sido filtrada o descubierta independientemente por los atacantes. Microsoft tiene la responsabilidad de actuar (por volumen de uso, por recursos disponibles y por ser objetivo principal del malware) mucho más rápido. Wheeler, uno de los descubridores del fallo, piensa que no: que hay muchos problemas de seguridad, y que es normal que Microsoft se dedique a los que están siendo explotados con prioridad. Como este no era público hasta hace poco, no piensa que sea demasiado tiempo.

Para colmo, se ha dado a conocer que desde el IBM ISS X-Force, también se notificó a Microsoft otra vulnerabilidad en 2008, identificada con el CVE-2008-0020, en la misma librería Msvidctl.dll de DirectShow. Esta todavía no ha sido reconocida por Microsoft, pero es probable que sea parcheada junto con la CVE-2008-0015.

Microsoft acumula así dos vulnerabilidades en DirectShow que se sabe que están siendo aprovechadas por atacantes (CVE-2009-1537 y CVE-2008-0015) y otra de la que no se sabe demasiado (CVE-2008-0020).

Por otro lado, en el "advisory" oficial de Microsoft se ofrecía información interesante. Por ejemplo, limita el problema a Windows XP y 2003. También enumera nuevos CLSID a los que se les puede activar el Kill Bit para evitar que sean explotables a través de Internet Explorer. Esto puede significar que son potenciales nuevos vectores de ataque que podrían ser usados para aprovechar la vulnerabilidad. Los ataques estaban llevándose a cabo a través de un solo CLSID (asociado a una librería) para aprovechar la vulnerabilidad, pero al parecer existen más, que Microsoft bloquea ahora para prevenir futuros ataques hasta que el problema sea solucionado por completo.

Se recomienda en todo caso, ejecutar la herramienta que Microsoft ha publicado para activar todos los Kill Bits de los CLSID implicados, que si bien no soluciona el fallo de raíz, evita que Internet Explorer se convierta en un vector de ataque.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Vulnerability in Microsoft Video ActiveX Control Could Allow Remote Code
Execution
http://www.microsoft.com/technet/security/advisory/972890.mspx

Microsoft Security Advisory: Vulnerability in Microsoft Video ActiveX
control could allow remote code execution
http://support.microsoft.com/kb/972890/en-us

http://www.eweek.com/c/a/Security/Was-Microsoft-Slow-to-Patch-Video-ActiveX-Vulnerability-130458
Was Microsoft Slow to Patch Video ActiveX Vulnerability?

miércoles, 8 de julio de 2009

Vulnerabilidad de Cross-Site Scripting en IBM Tivoli Identity Manager

Se ha anunciado una vulnerabilidad en IBM Tivoli Identity Manager por la que un atacante remoto podría construir ataques de cross-site scripting.

Tivoli Identity Manager es un producto de IBM destinado a realizar una gestión de la información de usuarios automatizada y basada en políticas que permite gestionar con eficacia cuentas de usuario, permisos de acceso y contraseñas desde su creación hasta su caducidad, en entornos y recursos de IT heterogéneos.

El problema reside en que no se filtran adecuadamente las entradas de código HTML introducidas por el usuario antes de mostrar una respuesta.
Esto podría ser aprovechado por un atacante remoto para insertar código script y HTML en la sesión del navegador del usuario atacado.

El código se origina desde el sitio que ejecuta Tivoli Identity Manager en el contexto de seguridad de este sitio. Con ello el atacante podría acceder a las cookies (incluyendo las de autenticación) y a información recientemente enviada, además de poder realizar acciones en el sitio haciéndose pasar por la víctima.

IBM ha publicado las actualizaciones: APARs IZ54310 y IZ54311; Interim Fix 5.0.0.6-TIV-TIM-IF0028 disponibles desde:
http://www-01.ibm.com/support/docview.wss?uid=swg24023640


Antonio Ropero
antonior@hispasec.com


Más información:

IBM Tivoli Identity Manager, ver 5.0, Interim Fix 5.0.0.6-TIV-TIM-IF0028
http://www-01.ibm.com/support/docview.wss?uid=swg24023640


martes, 7 de julio de 2009

Un fallo en la clase IO::Socket::SSL de Perl permite falsificar certificados

Se ha detectado un error en la validación de certificados en la clase IO::Socket::SSL del modulo IO::Socket::INET de Perl. El fallo permitiría a un atacante remoto eludir restricciones de seguridad a través de un certificado especialmente manipulado.

Perl es un lenguaje de programación en script diseñado a finales de los 80, está basado en un estilo de bloques como los del C e incorpora características típicas de la programación en shell.

SSL (TLS en su última versión) es un protocolo de comunicación cifrado que usa clave publica y privada que permite autenticar a un servidor o usuario a través de (entre otros métodos) certificados asociados a un dominio.

Este error en la correcta validación de un certificado SSL que permitiría a un atacante generar un falso certificado con un prefijo similar al que se quiere suplantar y la aplicación en Perl no lo detectaría como inválido. De este modo un atacante podría generar un certificado para el dominio www.ejem y suplantar entre otros a www.ejemplo.com, siempre que la aplicación que acceda a este certificado esté programada en Perl y use la clase IO::Socket::SSL afectada.


Victor Antonio Torre
vtorre@hispasec.com


Más información:

Perl v1.26 2009.07.03
http://cpansearch.perl.org/src/SULLR/IO-Socket-SSL-1.26/Changes
http://cpansearch.perl.org/src/SULLR/IO-Socket-SSL-1.26/README

lunes, 6 de julio de 2009

Mitos y leyendas: El Directorio Activo (II) (Instalación segura)

Una vez creado el dominio a través de un primer controlador , es muy aconsejable agregar un nuevo controlador para obtener ventajas de seguridad. Un segundo controlador proporciona un sistema de seguridad adicional en caso de fallo. Además supone un buen balance de carga para el sistema en caso de que miles de usuarios hagan uso del Directorio Activo y deba soportar muchas peticiones.

Habitualmente la manera tradicional de agregar un controlador de dominio a un dominio existente es la instalación de un Windows 2000 Server, 2003 o 2008 y ejecutar la herramienta dcpromo.exe. Los pasos durante la instalación de este segundo controlador son relativamente sencillos, guiados a través de un asistente que explica de forma más o menos detallada cada paso.

Una vez en marcha, comienza la replicación por red de la información desde el primer controlador original, de forma que se duplica la base de directorio del Directorio Activo y ambos sistemas poseerán la misma información. A partir de Windows 2003 se introdujo un nuevo método (Install From Media, IFM) mucho más efectivo que además obliga a realizar una copia de seguridad que se utilizará para la replicación. La táctica consiste en la instalación de un segundo controlador de dominio a partir de una copia de seguridad del primero, sin necesidad de replicar la base de datos a través de la red.

Ventajas

Esto es importante con respecto a la seguridad y el rendimiento porque:

* Obliga a realizar una copia de seguridad del controlador primario.
* Impide que la información de replicado se desplace por la red en caso de que los datos viajen por un canal no seguro.
* Ahorra tiempo y recursos porque no hay necesidad de que los datos se repliquen por la red. En una LAN quizá esto no suponga un problema, pero en sistemas de larga distancia, cualquier dato perdido o mal interpretado puede llegar a crear inconsistencias en las bases de datos.

Creando una copia de seguridad

La utilidad más adecuada en este caso es ntbackup.exe, que viene de serie en cualquier Windows excepto Vista. En ella se debe indicar que se quiere realizar una copia de respaldo del "estado del sistema" (opción solo disponible en los controladores de dominio). Después de unos minutos, esto creará un archivo con extensión BKF de (como mínimo) unos 500 megabytes.

Este fichero está "protegido" por la contraseña introducida durante el proceso de instalación del primer controlador de dominio. Este aspecto es importante porque induce a error. Existe un imperdonable fallo de traducción en los Windows 2003 que puede llegar a confundir a los administradores. Durante el proceso de instalación del directorio activo, el asistente pregunta en un momento dado por la "Contraseña de modo remoto" en el menú "Contraseña de admin. de Modo de restauración de directorio". Esta "Contraseña de modo remoto" es una traducción fallida de "Restore mode password", que queda mucho más claro en inglés. Esta contraseña no debe ser la misma que la de administrador, ni sirve para presentarse ante ningún recurso de dominio. Tampoco sirve para ningún tipo de modo remoto. En realidad su utilidad es la de entrar en el modo seguro del controlador de dominio cuando ha ocurrido algún tipo de error o se quieren realizar recuperaciones de objetos. También protege al fichero que acaba de crearse (o sea, para restaurarlo será necesario conocer la contraseña).

Usando la copia de seguridad en el controlador secundario

El archivo BKF puede ser trasladado a través de cualquier medio seguro al servidor secundario. Pero no se debe restaurar el archivo al "sitio original" que aparecerá por defecto al ejecutar ntbackup, sino a una carpeta separada. De ahí se tomarán los datos para promocionar más tarde el segundo servidor. Por ejemplo, se debe indicar que se va a restaurar el "estado del sistema" a una carpeta llamada "RestaurarADTmp". Esto se indica en las opciones avanzadas del programa de restauración.

Promocionando finalmente el servidor

Ahora es el momento de promocionar el servidor, pero debe hacerse también de una manera diferente, arrancando las opciones avanzadas de dcpromo.exe para poder elegir la opción de instalar el controlador desde una carpeta de restauración. Esto se consigue con:

dcpromo.exe /adv

De esta forma aparecerá en el asistente una nueva opción que permitirá elegir de dónde conseguir la información para instalar el controlador de dominio adicional. Se le debe indicar la carpeta creada a tal efecto (en este caso RestaurarADTmp), indicarle la contraseña de restauración, y el dominio será instalado.

La copia de seguridad debe ser descartada, por defecto, antes de 60 días (para dominios creados antes de Windows 2003 SP1, 180 días para dominios posteriores). Si se restaura después de ese tiempo, se corre el riego de sufrir inconsistencias entre los diferentes controladores. Ese es el valor del tombstone (lápida), tiempo de "vida" de los objetos borrados, o sea, el tiempo que permanecen en una especie de papelera desde donde se pueden recuperar. Este valor también sirve para evitar el riesgo de replicaciones entre controladores que no se han comunicado en todo ese tiempo.


Sergio de los Santos
ssantos@hispasec.com


Más información:

una-al-dia (25/06/2009) Mitos y leyendas: El Directorio Activo (I) (Conceptos)
http://www.hispasec.com/unaaldia/3897

domingo, 5 de julio de 2009

0 day en la librería msvidctl.dll de Microsoft Windows

Malos momentos para Microsoft. Se acaba de detectar un nuevo 0 day en Windows que está siendo aprovechado activamente. Microsoft no ha reconocido todavía el fallo, pues ha sido "destapado" por terceras partes. El exploit es público, y parece que (como viene siendo habitual) muchas páginas legítimas comprometidas están sirviendo para infectar los sistemas.

El fallo en cuestión es un desbordamiento de memoria intermedia basado en pila en la función 'MPEG2TuneRequest' de la librería msvidctl.dll. Un atacante remoto podría aprovechar esto para ejecutar código arbitrario con los permisos del usuario bajo el que se ejecuta el navegador.

La única contramedida disponible es la activación del kill bit del control. Es posible hacerlo guardando este archivo con extensión .reg y ejecutarlo como administrador:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\
ActiveX Compatibility\{0955AC62-BF2E-4CBA-A2B9-A63F772D46CF}]
"Compatibility Flags"=dword:00000400

No se ha confirmado aún a qué versiones de Windows en concreto afecta. La detección del JavaScript que explota el fallo es bastante pobre todavía. Según VirusTotal, solo McAfee, AntiVir, VirusBuster y Microsoft lo reconocen (recordando siempre que esto puede cambiar en un entorno de escritorio). El ejecutable que descarga sí tiene un mejor ratio de detección.

Malos momentos para Microsoft, puesto que acumula dos 0 day sin solución por ahora. A finales de mayo Microsoft reconocía un problema de ejecución de código explotable a través de archivos de QuickTime. En el posterior ciclo de actualizaciones de junio, no solucionó el problema, y tampoco parece que vaya a sacar un parche fuera de ciclo. La diferencia con este nuevo 0 day en msvidct.dll es que en aquel caso, no había información pública sobre cómo aprovecharlo. Esto hace mucho más peligroso este nuevo problema y sin duda hará que Microsoft actúe con mayor celeridad.


Sergio de los Santos
ssantos@hispasec.com


Más información:

29/05/2009 0 day en Microsoft DirectX
http://www.hispasec.com/unaaldia/3870

sábado, 4 de julio de 2009

Mes de los fallos en Twitter

La saga "El mes de los fallos en" comenzó en julio de 2006, cuando H.D Moore decidió dedicar un mes completo a publicar vulnerabilidades no parcheadas en los navegadores, a razón de una al día. La iniciativa, por lo original y relevante de la propuesta, fue todo un éxito. Otros investigadores le siguieron, creando el mes de los fallos en los núcleos (de cualquier sistema operativo) en noviembre de 2006, el mes de los fallos en Apple en enero de 2007... y algunos otros. Ahora es el momento de la Web 2.0.

Aviv Raff usará julio de 2009 como el mes de los fallos en Twitter. Su objetivo, como el de todos estos meses temáticos, es el de mejorar la seguridad a través de la presión mediática, y no solo la de Twitter. El resto de plataformas 2.0 puedan aprender algo de los problemas ajenos y por tanto prevenir. Por ejemplo, algunas de las vulnerabilidades encontradas hace tres años en el "Mes de los fallos en los navegadores" se creían "simples fallos" en el sentido de que no podían ser aprovechadas por atacantes. El hecho de hacerlas públicas llamó la atención de ciertos creadores de malware y consiguieron finalmente, meses después, aprovechar algunos de estos "bugs" para ejecutar código. En ese sentido supuso una buena alarma sobre los "bugs" a los que no se les da demasiada importancia.

"Month of Twitter Bugs" (MoTB) se centra en la API de Twitter, pero según Raff, bien podría tratarse de cualquier servicio 2.0 del momento. twitpwn.com es el dominio elegido para alojar el blog que publicará las vulnerabilidades. Raff reconoce que algunas vulnerabilidades son lo suficientemente peligrosas como para que se pueda crear un gusano, así que avisará con 24 horas de antelación al fabricante para que puedan ser corregidas. El blog es seguido por personal de Twitter, que participan en los comentarios activamente. De hecho, han corregido en cuestión de horas fallos ya publicados.

A medida que el escritorio se entiende menos sin conexión remota y se traslada hacia la red (o "la nube", como término de moda) y la línea que separa aplicaciones y servicios se difumina (casi siempre detrás de un navegador) no es de extrañar que las páginas y APIs de estas webs sean objetivo de ataques. Campañas llamativas como esta pueden ayudar a desvelar y prevenir vulnerabilidades, pero desde luego no las eliminarán. En el mundo de la programación y la informática en general se tiende insidiosamente a tropezar en la misma piedra siempre que se tiene la oportunidad. Por ejemplo, a medida que los sistemas operativos se han protegido (tarde, pero lo han hecho en cierta medida) contra ataques y malware, parece que nadie más a aprendido la lección, y los servicios en remoto que hoy en día se puede decir que forman parte de "la nube" (que a su vez forma parte del escritorio) parecen condenadas a repetir el mismo error.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Month of Twitter Bugs
http://aviv.raffon.net/2009/06/15/MonthOfTwitterBugs.aspx

TwitPwn (ab)using twitter since 2008!
http://twitpwn.com/

viernes, 3 de julio de 2009

Posible ejecución de código a través de SMS en iPhone

Apple está trabajando en un parche para arreglar un grave problema de seguridad que podría permitir la ejecución de código arbitrario en el iPhone al recibir un SMS especialmente manipulado. Hasta ahora los fallos graves se habían encontrado en su Safari integrado, cuando el usuario visitaba una página web de un atacante. Este problema hace posible que un atacante ejecute cualquier programa en el teléfono si necesidad de conexión a internet, con solo enviar un SMS que sea leído por la víctima.

El fallo se encuentra en la manera en la que el programa de SMS de iPhone procesa los mensajes cortos. No se han hecho públicos los detalles técnicos. Charlie Miller lo desveló en la conferencia SyScan en Singapur, al enviar un SMS que provocaba que la aplicación de mensajería del teléfono dejase de responder. Aunque dice no haber determinado todavía cómo aprovechar este fallo para ejecutar código, parece bastante convencido de poder lograrlo.

La aplicación que procesa los SMS (al contrario que otras que se encuentran más protegidas en el iPhone) se ejecuta bajo los privilegios de root, con lo que la ejecución de código tendría total control del dispositivo. Un atacante podría desde realizar llamadas a números especiales hasta abrir el micrófono del aparato y espiar conversaciones.

Miller dará todos los detalles en la Black Hat a finales de julio. Dice haber avisado a Apple y que está trabajando en una solución, que se hará disponible antes del famoso encuentro. Miller es coautor del libro "The Mac Hacker's Handbook".

Lo más probable es que esta vulnerabilidad no sea explotada de forma masiva por atacantes, pero abre un vector de ataque muy interesante. iPhone adopta medidas de seguridad muy lógicas en su sistema operativo: los paquetes deben estar firmados por Apple (excepto si el teléfono está "jailbraked") y muchas de sus aplicaciones se mueven dentro de una sandbox que impide que accedan a zonas sensibles del dispositivo. Sin embargo el programa que procesa los SMS no lo hace, y esto lo convierte en un vector de ataque muy atractivo, puesto que se puede transmitir código binario en un mensaje corto. El hecho de que el número de caracteres esté limitado parece irrelevante, puesto que se pueden enviar un número indefinido de SMS y el programa los reensamblará.


Sergio de los Santos
ssantos@hispasec.com


Más información:

Apple patching serious SMS vulnerability on iPhone
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9135090

jueves, 2 de julio de 2009

Actualizaciones de seguridad para NetBSD

NetBSD ha publicado actualizaciones de seguridad para OpenSSH, ntp y hack que corrigen diferentes problemas de seguridad. NetBSD es una implementación Unix de la familia *BSD, constituidos por NetBSD, OpenBSD y FreeBSD. Se trata de sistemas operativos de código abierto creados con la seguridad como principal motivación.

La actualización para OpenSSH, el conjunto de herramientas basado en el protocolo SSH, soluciona una debilidad en el manejo de errores que podría permitir a un atacante capturar hasta 32 bits en texto plano de bloques arbitrarios procedentes de tráfico cifrado con el modo CBC (Cipher Block Chaining).

Para ntp, se corrigen dos vulnerabilidades que podrían permitir a un atacante remoto ejecutar código arbitrario con los permisos del usuario ntp. Las vulnerabilidades, desbordamiento de memoria intermedia basada en pila, se encuentran en las funciones "cookedprint" y "crypto_recv", pertenecientes al comando ntpq, encargado de efectuar consultas a servidores ntp. Un atacante remoto podría ejecutar código arbitrario en un sistema que use el comando ntpq contra un servidor atacante a través de paquetes especialmente manipulados.

La tercera y última actualización es para Hack, un popular juego de mazmorras en modo texto basado en Rogue. Se han encontrado múltiples vulnerabilidades que podrían permitir a un atacante ejecutar código arbitrario con los privilegios del grupo "games".


David García
dgarcia@hispasec.com


Más información:

OpenSSH
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-005.txt.asc
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5161

ntp
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-006.txt.asc
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1252
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0159

Hack
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2009-007.txt.asc
http://homepages.cwi.nl/~aeb/games/hack/hack.html