miércoles, 30 de noviembre de 2011

Actualización de seguridad para Adobe Flex SDK

Adobe ha publicado una actualización de seguridad destinada a corregir una vulnerabilidad importante en Adobe Flex SDK 4.5.1 y 3.6 (y anteriores de sus respectivas ramas) para Windows, Macintosh y Linux. La vulnerabilidad afecta a una gran mayoría de las aplicaciones desarrolladas en este entorno.

Esta vulnerabilidad, con CVE-2011-2461, podría permitir a un atacante la realización de ataques cross-site scripting en aplicaciones Flex. Adobe recomienda a los usuarios de las versiones afectadas de Adobe Flex SDK actualizar el software, verificar si los archivos SWF de sus aplicaciones son vulnerables, y actualizar cualquier archivo SWF vulnerable usando las instrucciones y herramientas proporcionadas por Adobe.

Para la actualización de las versiones y de las aplicaciones afectadas se recomienda seguir las instrucciones descritas en:

Más información:

Security update available for Flex SDK

Flex Security Issue APSB11-25


Antonio Ropero
Twitter: @aropero

martes, 29 de noviembre de 2011

Malware y certificados digitales

Este año los certificados han estado en boca de todos. Comodo y DigiNotar han protagonizado algunos "escándalos". Pero continúa el problema con los certificados, ahora en forma de malware, robos y factorización.

Microsoft invalidaba en noviembre dos nuevos certificados de la compañía "DigiCert Sdn. Bhd" (Digicert Malasia), una entidad de certificación (CA) subordinada de Entrust y GTE CyberTrust. De hecho, se han añadido a la (tocada ya por tercera vez en 2011) lista de certificados no confiables en la mayoría de navegadores.

En los casos de Comodo y DigiNotar, la razón para revocarlos fue el robo. Sin embargo, en esta última ocasión el motivo para revocarlos ha sido diferente. Esta entidad había emitido 22 certificados con claves de 512 bits.

¿Por qué son inseguros los certificados con claves de 512 bits?

Normalmente se están usando claves RSA de 2048 o 4096 bits de longitud. Emitir claves de 512 bits es insuficiente desde hace tiempo. En resumidas cuentas: calcular todas las posibilidades es "abordable" y resulta relativamente viable por fuerza deducir la clave privada. Para conseguirlo, es necesario encontrar los dos números primos que, multiplicados, resultan en ese número de longitud 512 bits. O sea, el famoso problema de la factorización.

Así, un atacante, a partir de la clave pública que ya se encuentra en un certificado, podría deducir la clave privada. Esta información le permitiría (entre otras acciones) firmar cualquier software. La validación sería correcta (la clave pública asociada está avalada por el propio certificado) y podría parecer legítimo y que proviene de la entidad a la que pertenece el certificado.

Se confirmó poco después

Cuatro días después de la revocación de Microsoft, el 14 de noviembre, F-Secure anunciaba el descubrimiento de un malware firmado digitalmente con un certificado válido perteneciente a DigiCert. Todo hacía pensar en un caso de robo de certificado. Aparecieron después más muestras de malware firmado.

He descargado ese malware y comprobado su certificado. Está emitido para un dominio. O sea, su principal función es la autenticación del servidor por SSL, no firmar código. Normalmente los certificados tienen una restricción técnica para su uso, y un certificado utilizado para autenticar un dominio no debería emplearse para firmar software. Pero estos certificados no solo están lastrados por los 512 bits usados para las claves, sino que ni siquiera contienen esta restricción de uso.


Según Fox-it, de hecho, los atacantes buscaron certificados vulnerables de esta manera: probablemente analizaron por todo Internet servidores SSL (puerto 443) y sacaron certificados públicos. Comprobaron sus bits de clave RSA y sus restricciones. Una vez con un buen número de certificados "débiles" disponible, factorizaron las respectivas claves privadas y ya podían suplantar la personalidad de estos certificados.



¿Es sencillo romper la seguridad de claves RSA de 512 bits?

En una una-al-día de septiembre de 1999, escribíamos lo siguiente:


"Un equipo de personas de todo el mundo, con casi 300 ordenadores, consigue completar la factorización RSA-155 en poco más de 5 meses. Este resultado demuestra de forma patente, una vez más, que las claves públicas RSA de 512 bits no suponen un obstáculo frente a cualquier organización de medianas proporciones."
Con lo que podemos hacernos una idea de lo "complicado" que podría resultar hoy en día. Por aquel entonces, la legislación norteamericana no permitía exportar al extranjero productos con claves RSA de longitud superior a los 512 bits.

¿Por qué emitir certificados con claves tan simples?

Entrust se pregunta lo mismo. Es la compañía que emitió certificados intermedios a "DigiCert Sdn. Bhd" (Digicert Malasia) a la que se le permitió distribuir certificados S/MIME y SSL. Esta a su vez emitió los certificados con claves de 512. Esto según "Entrust" violaba los acuerdos y estándares.

Más información:

Malware Signed With a Governmental Signing Key

MSA-2641690 - Los certificados digitales fraudulentos podrían permitir la suplantación de identidad

Factorización de RSA-155

Competición RSA


Sergio de los Santos
Twitter: @ssantosv

José Mesa Orihuela


lunes, 28 de noviembre de 2011

Investigadores descubren posible vulnerabilidad en el proceso de actualización de impresoras HP Laserjet

Un grupo de investigadores de la Universidad de Columbia afirman haber descubierto una vulnerabilidad que afecta a las impresoras HP LaserJet y que podría permitir a un atacante remoto emplear la impresora como punto de entrada de otro tipo de ataques o provocar que se caliente en exceso.

En una demostración de las posibilidades del problema, los investigadores Salvatore Stolfo y Ang Cui de la Universidad de Columbia, demostraron como desde otro equipo podían enviar una actualización del firmware de la impresora. Llegó a calentarse de tal modo que empezó a echar humo hasta dejar de funcionar y quemó el papel hasta volverlo marrón.

Las impresoras una vez atacadas pueden ser controladas de forma remota a través de Internet, con la potencial posibilidad de robo de información personal o lanzar otros ataques a diferentes redes o sistemas desde el dispositivo.

El investigador Ang Cui en una imagen de la Universidad
de Columbia
Según los investigadores, realizaron ingeniería inversa sobre el software que controla las impresoras HP LaserJet. Estas impresoras permiten actualizaciones del firmware a través de un proceso llamado "Remote Firmware Update". Cada vez que la impresora acepta un trabajo, comprueba si existe una actualización de su software incluida en ese trabajo. Pero según afirman, las impresoras no comprueban la fuente de la actualización, y que ni siquiera se usa una firma digital para verificar su autenticidad. De esta forma cualquiera puede construir una actualización de firmware maliciosa diseñada para realizar acciones maliciosas.

HP ha respondido a estas afirmaciones asegurando que:
"Ha habido informaciones sensacionalistas e inexactas sobre una potencial vulnerabilidad de seguridad en algunas impresoras HP LaserJet. Ningún cliente ha comunicado accesos no autorizados. Especulaciones respecto a que dispositivos puedan potencialmente arder debido a un cambio de firmware es falso".

"Las impresoras HP LaserJet tienen un elemento de hardware llamado «interruptor térmico» diseñado para prevenir el sobrecalentamiento o causar un incendio. Esto no puede ser modificado por un cambio de firmware o esta vulnerabilidad propuesta".
Sin embargo tampoco niega totalmente la existencia de algún tipo de problema:

"Mientras HP ha identificado una potencial vulnerabilidad de seguridad en algunas impresoras HP Laserjet, ningún cliente ha anunciado accesos no autorizados. La vulnerabilidad específica existe en algunos dispositivos HP Laserjet si se sitúan públicamente en Internet si firewall. En una red privada algunas impresoras pueden ser vulnerables si se modifica el firmware de un dispositivo desde una parte confiable de la red".

"HP está desarrollando una actualización del firmware para mitigar este problema y ésta se va a comunicar de forma proactiva a los clientes y socios que puedan verse afectados".
Básicamente, HP admite que existe un problema que afecta a sus impresoras (sin determinar totalmente su alcance), pero no cree que haya ocurrido ningún ataque, y tampoco ve posible que las impresoras puedan llegar a arder ante esta posibilidad.

Keith Moore, jefe de tecnología para la división de impresoras de HP, afirmó que desde 2009 las nuevas impresoras de HP requieren actualizaciones de firmware firmadas digitalmente. Sin embargo, los investigadores de la Universidad de Columbia afirmaron haber comprado una de las impresoras empleadas en la prueba el pasado septiembre en una tienda de Nueva York.

Actualmente las informaciones por ambas partes son un tanto contradictorias, hasta que los investigadores no publiquen un aviso o "paper" específico en el que describan los problemas; o analizar un aviso de seguridad detallado de HP y el parche que publiquen, no se puede afirmar el alcance real de los ataques

Más información:

Exclusive: Millions of printers open to devastating hack attack, researchers say

Security researchers say HP printers vulnerable to hackers

HP LaserJet printers at risk of fiery hacker attack

HP Refutes Inaccurate Claims; Clarifies on Printer Security

HP: Printers Will Stop Themselves Before Hackers Set Them On Fire


Antonio Ropero
Twitter:@aropero

domingo, 27 de noviembre de 2011

Actualización del kernel para Red Hat Enterprise Linux 6

Red Hat ha publicado una actualización del kernel para toda la familia Red Hat Enterprise Linux 6 que solventa 12 vulnerabilidades que podrían ser aprovechadas por un atacante para provocar denegaciones de servicio, revelar información sensible o evitar determinadas protecciones de seguridad.

Los problemas corregidos se deben a errores en IPv6; en las implementaciones CIFS (Common Internet File System), FUSE (Filesystemin Userspace) y EFI GUID PartitionTable (GPT); en el driver b43; en el acceso a estadísticas I/O del subsistema taskstats y por último en la herramienta perf perteneciente a la implementación PerformanceEvents.


Además se han solucionado otros fallos de menor importancia. Ésta actualización está disponible desde Red Hat Network.

Más información:

Important: kernel security and bug fix update


Antonio Ropero
Twitter: @aropero

sábado, 26 de noviembre de 2011

Vulnerabilidad en el Centro de Software de Ubuntu permitiría falsificar aplicaciones

Canonical, desarrolladora de Ubuntu, ha corregido recientemente una vulnerabilidad presente en su Centro de Software, destinado a la descarga, instalación y gestión centralizada de aplicaciones por parte del usuario.

La vulnerabilidad (CVE-2011-3150), debida a la incorrecta validación de los certificados al realizar conexiones seguras, permitiría falsificar aplicaciones, a través de un ataque MITM (man in the middle), facilitando que un usuario descargara e instalara aplicaciones especialmente modificadas haciéndolas pasar por oficiales de Ubuntu.

Parece un error que consigue un efecto parecido al "Evilgrade".

Las versiones afectadas son 12.04, 11.10, 11.04 y 10.10. Se recomienda aplicar los parches disponibles a través del Gestor de Actualizaciones.

Más información:

iTunes 10.5.1 corrige vulnerabilidad conocida desde 2008

USN-1270-1: Software Center vulnerability



José Mesa Orihuela

viernes, 25 de noviembre de 2011

Un parche de Apache 2.x no soluciona realmente una vulnerabilidad

A principios de octubre alertamos sobre la vulnerabilidad presente en Apache 2.x. El fallo permitiría a un atacante acceder a partes de la red del servidor no habilitadas en un principio al público, a través de un fallo en la directiva "RewriteRule" del módulo "mod_proxy".

El parche anterior no soluciona totalmente la vulnerabilidad encontrada (CVE-2011-3368) puesto que no se llegaron a comprobar las URI basadas en esquemas. Por tanto, se podría volver a acceder de nuevo a partes sensibles de la red interna del servidor si las reglas del proxy inverso no se encuentran bien configuradas (como ocurría con la vulnerabilidad anterior).

Ejemplo:

En un servidor ya actualizado con el parche para CVE-2011-3368 y con una regla como la siguiente:

RewriteRule ^(.*) http://10.20.30.40$1
ProxyPassMatch ^(.*) http://10.20.30.40$1

Se conseguiría acceder a través de una petición como esta:

GET @localhost::8880 HTTP/1.0

Al recurso interno en http://10.20.30.40:8880. Pudiendo ser cualquier puerto de un servidor interno de la red, por ejemplo.

Una solución temporal consistiría en corregir las reglas iniciales, añadiendo el carácter "/".

RewriteRule ^(.*) http://10.20.30.40/$1
ProxyPassMatch ^(.*) http://10.20.30.40/$1

Se ha publicado un parche temporal para esta "nueva" vulnerabilidad a la que le ha sido asignado el CVE-2011-4317.

Más información:

[RFC] further proxy/rewrite URL validation security issue (CVE-2011-4317)

Revelación de información a través de 'mod_proxy' en Apache 2.x

Apache HTTP Server Reverse Proxy/Rewrite URL Validation Issue



José Mesa Orihuela


jueves, 24 de noviembre de 2011

Google activa Forward Secrecy (FS) en sus servicios

Google viene ofreciendo desde hace un tiempo una serie de mejoras de seguridad en servicios como Gmail, al incorporar por defecto HTTPS y cifrado de las búsquedas. A esto hay que añadir una nueva funcionalidad anunciada esta semana: la activación por defecto del protocolo "Forward Secrecy".

Cuando se utiliza criptografía de clave pública (por ejemplo en TLS/SSL), se utilizan protocolos de acuerdo de claves de sesión. Estas claves se consensúan entre las dos partes que van a cifrar su conversación (cliente y servidor, por ejemplo) y se  intercambian de forma secreta (en un medio "público" como Internet) usando las claves privadas de ambas partes. Básicamente, el cliente (navegador) genera una clave pública de sesión y se la envía al servidor firmada con su clave pública para que solo el servidor pueda descifrarla. Ahora que las dos partes conocen la clave de sesión que van a usar, comienza la comunicación segura.

Si un atacante robase este tráfico cifrado, necesitaría conocer la clave privada del servidor para descifrar la contraseña de sesión. Tendría dos opciones: o bien romper por fuerza bruta la clave privada (no sabemos lo sencillo que puede resultar dentro de unos años), o bien robarla. Con esto descifraría la clave de sesión de ese tráfico y podría observar los datos en claro de cualquier conexión pasada, puesto que todas han sido firmadas con la misma clave pública.

La función de FS es impedir esto, evitando que se genere más de una clave a partir de un mismo material criptográfico. Para ello se basa en la generación de "claves efímeras" ECC y en la mejora de seguridad sobre los tickets de sesión.
  • Generalmente, para implementar TLS/SSL, se utiliza la combinación RSA-RC4-SHA en la mayoría de los navegadores. Ahora, en Google se usaría ECDHE-RSA-RC4-SHA. ECDHE es un protocolo de confirmación de clave efímera, basado en Diffie Hellman mediante criptografía de curva elíptica (ECC). Básicamente esto supone que el servidor genera una clave pública Diffie-Hellman para cada sesión y firma. A su vez el cliente también genera una clave pública y mediante Diffie-Hellman se crea una clave mutua final. El hecho de crear en cada sesión una clave pública diferente supone que si en algún momento se consiguiera romper alguna de ellas, el atacante sólo tendría acceso a la sesión asociada a esa clave, haciendo imposible recuperar la comunicación completa de años atrás, por ejemplo.
  • Cuando se establece una nueva sesión, el servidor cifra su estado y lo envía al cliente en forma de ticket. Posteriormente el cliente lo reenvía para continuar con la sesión previa. Debido a que ese ticket contiene información sobre la sesión (las claves de cifrado), con la nueva implementación de clave efímera se consigue que los tickets de sesión nunca permanezcan almacenados y siempre en un estado continuo de rotación.

A efectos prácticos, y como explica la propia Google, si se envía un email cifrado y algún atacante capturase el tráfico con la esperanza de poder romper el cifrado con la tecnología de dentro de 10 años, esto se lo impediría. Tener en sus manos la clave privada del servidor no le serviría.

Google ha confirmado que esta implementación está ya disponible para Chrome y Firefox en servicios como Gmail, SSL Search, Docs y Google+, excepto para Internet Explorer que todavía no soporta ECDHE.  Google ha publicado el trabajo realizado sobre la librería OpenSSL necesario para implementar esta funcionalidad.

Más información:

Protecting data for the long term with forward secrecy

Forward secrecy for Google HTTPS


José Mesa Orihuela

Sergio de los Santos
Twitter: @ssantosv

miércoles, 23 de noviembre de 2011

Grave vulnerabilidad remota en el cliente iPrint de Novell

Novell ha publicado una actualización para corregir una vulnerabilidad en Novell iPrint Client para Windows, que podría permitir a un atacante remoto ejecutar código arbitrario en los sistemas vulnerables.

El problema (con CVE-2011-3173), que fue reportado a través de TippingPoint's Zero Day Initiative (ZDI-11-309), reside en el componente nipplib.dll. La vulnerabilidad puede permitir a un atacante crear código HTML malicioso de forma que al cargarse por el usuario atacado provoque un desbordamiento de búfer en GetDriverSettings(), con la posibilidad de ejecutar código arbitrario en el sistema afectado. El código se ejecuta con los privilegios del usuario atacado.

Se recomienda actualizar a Novell iPrint Client versión 5.72.

Más información:

Novell iPrint Client nipplib.dll GetDriverSettings Remote Code Execution Vulnerability

Novell iPrint Client nipplib.dll GetDriverSettings Remote Code Execution Vulnerability


Antonio Ropero
twitter: @aropero

martes, 22 de noviembre de 2011

RealNetworks publica actualización para RealPlayer

RealNetworks ha anunciado una actualización para corregir 19 vulnerabilidades en RealPlayer, que podrían permitir a un atacante comprometer los sistemas afectados.

Se ven afectadas las versiones RealPlayer 11.0 a 11.1, RealPlayer SP 1.0 a 1.1.5, RealPlayer 14.0.0 a 14.0.7 y RealPlayer para Mac 12.0.0.1701.

Los problemas afectan a diferentes aspectos del reproductor, incluyendo la reproducción de archivos AAC, MP4, IVR y MPG, así como con archivos codificados RV30, RV 20 y RV10. Y la mayoría de los problemas podrían permitir la ejecución remota de código arbitrario y comprometer los sistemas afectados.

Se recomienda actualizar a las versiones RealPlayer 15.0.0 (para Windows XP, Vista y Win7), RealPlayer 12.0.0.1703 para Mac OS X 10.3 a 10.6.

Más información:

RealNetworks, Inc. lanza una actualización de seguridad para resolver puntos vulnerables.


Antonio Ropero
Twister: @aropero

lunes, 21 de noviembre de 2011

Google Location Server: la propuesta anti-localización de Google

En abril de 2010 se hizo público que Google recolectaba "por error" información sobre las redes inalámbricas en el radio de acción de los coches encargados de realizar las fotografías de los mapas de Google Street View. No solo recolectaban las imágenes sino el nombre y MAC de las WI-FIs que detectaba a su paso. Ahora ofrecen la opción de que este dato no sea recogido.

Preliminares

Cuando Google se embarcó en la fotografía de las calles más importantes de las principales ciudades, usaba camiones que recorrían lentamente las avenidas. Lógicamente incorporaban sensores GPS. Pero además (y esto no lo habían comunicado) escáneres Wi-Fi que iban barriendo todo el espectro cercano al vehículo. Almacenaban el BSSID, ESSID e incluso la fuerza de la señal y lo asociaron todo a las coordenadas GPS en cada momento. Completaron así una enorme base de datos.

Con esto consiguieron que los dispositivos móviles sin GPS integrado también pudiesen posicionarse en el mapa y que, los que ya lo tenían, lo hiciesen incluso con mayor precisión y velocidad. Con solo una conexión a Internet (Wi-Fi o 3G) y sin necesidad de GPS, es posible hacer una consulta a Google enviando las redes inalámbricas que detecta el dispositivo en ese momento. Con esta información, los servidores devuelven una posición exacta en el mapa (extraída de la enorme base de datos que asocia Wi-Fi y GPS que recopilaron). Una forma de posicionar más eficaz, eficiente y barata de localizar un dispositivo.

Google en entredicho

Este descubrimiento generó bastante controversia aun tratándose de la recopilación sin permiso de datos "públicos" emitidos constantemente por los routers al exterior. Tras el escándalo,  diversos países de la Unión Europea tomaron medidas y exigieron una rectificación a Google con amenaza económica de por medio.

En septiembre, la empresa anunció que haría pública una resolución para evitar que sus servicios registraran los datos de los usuarios. El 14 de noviembre Google propone una resolución técnica para que sea el propio usuario el que decida si los datos de su WiFi pueden ser recolectados o no.

Su "solución"

El propietario de un punto de acceso que no quiera que su posición GPS y datos de red queden registrados en las bases de datos de Google debe añadir "_nomap" al nombre de la red inalámbrica. Google entenderá que debe ser eliminada toda aquella información asociada a ese SSID. Google deja así en manos del usuario informado de esta resolución, el formar parte de esa gran base de datos.

Ya lo ha hecho en anteriores ocasiones con otros servicios (Analytics, Adsense, Gmail...), no hay mas que buscar "Google opt-out" en el propio Google para conocer qué servicios permiten al usuario desligarse de la enorme recopilación de información que está recolectando el gigante.

Si esta medida se llevara a cabo y se unieran (como también propone la propia Google), otras entidades y proveedores a la iniciativa del "_nomap", simplemente con que un visitante accediera a través de una red con el nombre (por ejemplo) "CASA_nomap" a un servicio de localización de Google, automáticamente quedaría eliminado de la base de datos cualquier información referente a ese BSSID y ESSID almacenados  anteriormente.

¿Es una buena solución?

Esto podría tener efectos colaterales. El cambio del nombre de WiFi en determinados ámbitos (empresariales, principalmente), supondría tiempo y esfuerzo de reconfiguración de terminales móviles. En el caso de usuarios domésticos, la mayoría quizás ni siquiera posean los conocimientos necesarios para realizar la modificación del nombre de la red.

Con este movimiento, Google intenta evitar el posible castigo de la Unión Europea dejando la pelota del lado del usuario, pero solo una vez que el "daño" está hecho y el negocio montado. Ha recopilado toda la información que necesita para ofrecer un servicio de calidad, y luego permite que el usuario elimine su información, consciente de que será un porcentaje tan mínimo el que finalmente decida elimine su posición de la base de datos, que no afectará a la calidad del posicionamiento global que ofrece.

Como suelen hacer las empresas en estos casos, Google "vende" la opción como una mayor "oportunidad" para los dueños de puntos de acceso.

Más información:

"Greater choice for wireless access point owners"

Investigations of Google Street View



José Mesa Orihuela

Sergio de los Santos
Twitter: @ssantosv

domingo, 20 de noviembre de 2011

Vulnerabilidad en Zenprise Device Manager permitiría bloquear o espiar remotamente dispositivos móviles

Se ha descubierto un fallo en Zenprise Device Manager que permitiría realizar un ataque para robar las credenciales del panel de administración.

Zenprise Inc., empresa americana especializada en gestión, control y securización remota de dispositivos móviles como smartphones y tablets para el mercado empresarial, posee dentro de su línea de servicios el denominado Zenprise Device Manager (MDM) capaz de gestionar miles de Blackberry o iPhones de manera remota y centralizada.

Zenprise Device Manager es un software que permite manejar de forma centralizada todos los dispositivos móviles de una gran empresa a través de una interfaz web.

La firma francesa TEHTRI-Security ha descubierto un fallo que permitiría realizar un ataque CSRF para engañar a un usuario autenticado (a través de una URL especialmente modificada) y robar las credenciales del panel de administración. Si ese usuario fuera un administrador se podría realizar cualquier función a la que tenga acceso y por tanto llegar a bloquear todos aquellos terminales disponibles en la cuenta o espiarlos remotamente.

Debido al tipo de vulnerabilidad, el amplio uso de este software en el mercado empresarial (sobre todo en grandes corporaciones gubernamentales) y la diversidad de dispositivos que abarca (Android, iPhones/iPads, Blackberrys, Windows Mobile, Symbian y Palm), se recomienda encarecidamente la aplicación de la actualización disponible.

Más información:

Actualización

VU#584363 : Zenprise Device Manager CSRF vulnerability

[US-CERT VU#584363] Pwning a complete fleet of GSM/Tablets


José Mesa Orihuela

sábado, 19 de noviembre de 2011

Joomla! se actualiza y soluciona dos fallos de seguridad

Se han publicado las nuevas versiones de Joomla! 1.5.25 y 1.7.3, que solucionan dos graves fallos de seguridad.

Joomla! es un sistema de gestión de contenidos y framework web muy popular para la realización de portales web. Cuenta con una la gran cantidad de extensiones de fácil integración que le proporcionan un gran potencial.

La primera vulnerabilidad solucionada es común en ambas versiones. Este fallo permite predecir una contraseña cuando es regenerada por el sistema.

El segundo fallo solucionado solo afecta a las ramas 1.7.x y 1.6.x y se trata de un cross site scripting provocado por un error en el filtrado de los parámetros que recibe la aplicación. Esto permite ejecutar código javascript a través de una url especialmente diseñada.

Recomendamos actualizar a las versiones 1.5.25 o 1.7.3 que solucionan estos problemas.

Más información:

Joomla Released :

Security advisories:

Fix commit:


 
Víctor Antonio Torre



viernes, 18 de noviembre de 2011

Disponible la lección 11 de intypedia: Análisis y gestión de riesgos

En el servidor Web de intypedia, la Enciclopedia de la Seguridad de la Información, se encuentra disponible la Lección 11 titulada "Análisis y gestión de riesgos" del autor José Antonio Mañas (España).

La lección se encuentra destacada como último vídeo en la página web del proyecto:

En ella, Alicia le muestra a Bernardo los pasos que hay que seguir para realizar un correcto análisis de las amenazas a las que puede enfrentarse un sistema de información, su impacto y la consiguiente gestión de riesgos, recomendando algunas metodologías. La lección tiene una duración de 14:13 minutos y está formada por 4 escenas o capítulos:

Escena 1. Riesgos y protecciones en los sistemas de información.
Escena 2. Análisis de impacto y análisis de riesgos.
Escena 3. Gestionando los riesgos.
Escena 4. Recomendaciones. Metodologías.

El vídeo viene acompañado por 3 documentos en pdf que pueden descargarse desde el sitio Web de intypedia: el guión de la lección, las diapositivas de apoyo y los ejercicios para autoevaluación. En los próximos días estará disponible en el servidor Web de intypedia la versión en inglés de esta lección.

La siguiente entrega de la enciclopedia visual de la seguridad de la información será en diciembre de 2011 con la Lección 12 "Seguridad en redes WiFi", del autor Raúl Siles.


Jorge Ramió Aguirre
twitter: @intypedia

jueves, 17 de noviembre de 2011

Descubriendo el protocolo de Siri

Siri es un sistema de inteligencia artificial con reconocimiento de voz, que permite realizar diversas acciones sobre un teléfono. Esta utilidad se incorporó como novedad en los terminales iPhone 4S.

Oficialmente solo está disponible para este terminal, pero ya se ha portado de manera extra oficial a iPod 4G y existen rumores que indican que Apple podría estar pensando en lanzar esta aplicación para otros dispositivos.

Investigadores de Applidium han analizado el protocolo de comunicación usado por Apple para enviar información a sus servidores, donde procesa y analiza los datos para responder de la mejor manera posible.

Lo que han averiguado hasta ahora es que la comunicación con el servidor se realiza a través de HTTPS al servidor "guzzoni.apple.com" usando el protocolo HTTP con métodos no estándar para la comunicación.

Para sortear el cifrado, los investigadores crearon una entidad certificación SSL personalizada, la añadieron al teléfono, y firmaron con ella un certificado falso para el dominio "guzzoni.apple.com" también creado para la ocasión.

Así descubrieron que, por ejemplo:
  • El protocolo usado por Siri, añade el método HTTP "ACE" (en vez de usar un "GET").
  • Permite un tamaño de datos (Content-Length) de 2000000000.
  • Incorpora una cabecera "X-Ace-Host" con el identificador del dispositivo.
Más información:

Applidium blog:

Códigos:

Siri sobre iPod:

Siri sobre otros dispositivos:


Victor Antonio Torre


miércoles, 16 de noviembre de 2011

Corregido 0-day que afecta a servidores DNS BIND 9

El ISC (Internet Systems Consortium) ha publicado un parche que corrige una vulnerabilidad 0-day de denegación de servicio  en el servidor DNS BIND 9.

BIND 9 es uno de los servidores DNS más extendidos que tiene su origen en el proyecto de cuatro estudiantes de la universidad de Berkley a principio de los años 80. BIND es código libre, publicado bajo la licencia BSD.

La vulnerabilidad, hasta ahora desconocida, fue reportada por varias organizaciones independientes al ISC como un error que afectaba a las consultas recursivas. En concreto, el mensaje que quedaba en los logs era:

"INSIST(! dns_rdataset_isassociated(sigrdataset))"

El error apuntaba al archivo fuente 'query.c'.

Según la descripción del ISC, el error provoca el almacenamiento de un registro DNS no valido. Si ese registro es consultado posteriormente (o sea, se intenta resolver de nuevo) el proceso entra en un estado de error de aserción (assert) y muere.

ISC no ha publicado detalles técnicos sobre el parche aplicado e incluso se encuentra en fase de estudio sobre la naturaleza y forma del o los exploits usados en los ataques que se han observado.

Sobre el parche, ISC comenta que se centra en la parte de código que procesa la consulta a la caché de la petición efectuada por el cliente. Por una parte se impide a la caché devolver datos inconsistentes (un registro no válido) y por otro lado se previene la caída del proceso 'named' (nombre del proceso de BIND) si se ha detectado una petición de registro con formato no válido.

La vulnerabilidad, con el CVE-2011-4313, afecta a las versiones: 9.4-ESV, 9.6-ESV, 9.7.x, 9.8.x.

El error es explotable en remoto y no precisa de autenticación previa. Los parches están disponibles desde la página web del fabricante.

Más información:

BIND 9 Resolver crashes after logging an error in query.c



David García



martes, 15 de noviembre de 2011

Hemos probado la nueva FOCA 3.0

Una de las fases más importantes en el proceso de auditoría es la recogida de datos, denominada en inglés como "Fingerprinting". Dicha fase comprende una recolección de "todo aquello que puede ser conocido" sobre el o los objetivos de la auditoría.

Capturar y gestionar esa información es un arte y ciencia (a veces subestimada) que tiene capítulo propio en el área de inteligencia. A veces resulta increíble lo que puedes llegar a encontrar tirando de un pequeño hilo desapercibido. Se hace entonces indispensable contar con herramientas de calidad para discernir el grano de la paja.

La FOCA, en su recién lanzada versión 3.0, es precisamente una de esas herramientas que facilita, o mejor dicho, hace posible extraer, procesar y gestionar la información del objetivo.

En el departamento de auditoría de Hispasec hemos estado probándola durante las últimas semanas. Nada de casos de éxito prefabricados, sino en escenarios reales donde o no tienes nada donde rascar o tienes tanta información que su ruido impide distinguir lo importante.

Lo primero que ya nos gustó fue el enfoque por proyectos y la persistencia de estado que obviamente es indispensable. Otro detalle es que el árbol de opciones es prácticamente un paso a paso de las distintas subetapas sobre recolección y análisis de datos y metadatos. Una vez metes el dominio y dominios asociados comenzamos con la búsqueda pasiva.

¿Qué sabe la red de este dominio? El abanico de posibilidades brinda desde búsqueda con múltiples motores, consultas DNS, búsqueda por diccionario o escaneos PTR. Otro aspecto es la integración con Shodan y Robtex, auténticos monstruos de sabiduría y conocimiento sobre estructura de la red.

Durante esta fase la FOCA va añadiendo nodos con sus descripciones y datos. Es sorprendente comprobar cómo va traceando la red y dibujando su esquema. Si quieres centrar la atención a un servidor en concreto tienes opciones para ver el banner, qué rol tiene, hacerle un crawling o ver qué tipos de fichero aloja, etc. Incluso, aunque no se trata de un escáner de vulnerabilidades te muestra algunas de ellas, como los métodos inseguros, backups que no deberían estar ahí.

Donde despunta es en el apartado de metadatos. FOCA realiza una búsqueda de múltiples tipos de archivos, se los descarga, extrae los metadatos y los analiza. El proceso es bastante rápido. Tardó segundos en procesar más de 600 documentos de tipo pdf, doc y xls. Tras este análisis presenta un sumario de la información donde encuentras nombres de usuario, rutas internas, impresoras, software usado, direcciones de correo, sistema operativo usado, contraseñas y dominios o IPs adicionales.

Otro punto a destacar es la generación de informes y el sistema de plugins. A la FOCA se le puede añadir extras, es una herramienta muy atractiva para ir añadiendo extensiones.

Como aspectos a mejorar, hemos echado en falta una interfaz más intuitiva desde el punto de vista de los módulos que se están lanzando en cada momento, tener a mano un panel donde poder lanzar/parar los diferentes módulos y ver el estado en el que se encuentran. Si bien las ventanas de logs y tareas están ahí falta un poco de organización y puedes llegar a perderte o preguntarte ¿qué estaba haciendo ahora?

Otro punto negativo es cuando se usa el motor Exalead. Al usar CAPTCHA la ventana aparece continuamente para que prosiga la búsqueda y resulta un poco repetitivo, lo que nos hizo prescindir del mencionado motor en las búsquedas automatizadas.

En definitiva, algo útil que nos ha permitido ahorrar bastante tiempo en esa primera fase de auditoría, a veces tediosa.

Enhorabuena al equipo de Informática64 que la ha hecho posible.

Más información:

FOCA


Laboratorio Hispasec