martes, 30 de junio de 2015

Más de 70.000 vulnerabilidades

Según ha informado Mitre.org, el pasado 24 de junio la lista de CVEs sobrepasó los 70.000 identificadores únicos con nombres públicamente conocidos.  

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. Se hace 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 vulnerabilidades es por su CVE.

La lista de identificadores CVEs, también conocidos en la comunidad como nombres CVE, números CVE, entradas CVE, CVE-IDs o simplemente CVEs, empezó en 1999 con solo 321 entradas. En la actualidad se ha convertido en un estándar internacional para la identificación de vulnerabilidades. Tanto los profesionales de la seguridad, como los fabricantes de todo el mundo usan el identificador CVE como un método estándar que no solo permite identificar las vulnerabilidades; sino que también facilita el trabajo de clasificación y las referencias cruzadas entre productos, servicios y repositorios.

El identificador CVE, tiene la forma CVE-AAAA-NNNN (p.ej. CVE-2015-1234), donde AAAA representa el año en que se reportó o se conoció la vulnerabilidad, y el número NNNN se asigna según el organismo tiene conocimiento de la vulnerabilidad. Hasta 2014 se estimaba que con cuatro dígitos para el número de vulnerabilidad era suficiente para identificar todas las vulnerabilidades del año. Pero dado el aumento del número de vulnerabilidades anuales, se estimó la necesidad de ampliar el número de dígitos y en la actualidad no hay un límite de dígitos.

Cada uno de los 70.000 identificadores de la Lista CVE incluye el identificador CVE, una breve descripción de la vulnerabilidad y todas las referencias pertinentes como análisis de la vulnerabilidad, avisos o parches.

La lista de CVEs se encuentra disponible en https://cve.mitre.org/cve desde donde se pueden realizar consultas individuales o descargar la lista completa en diversos formatos.

Más información:

CVE List Surpasses 70,000 CVE-IDs



Antonio Ropero
Twitter: @aropero

lunes, 29 de junio de 2015

Diversas vulnerabilidades en IBM Security Directory Server

IBM ha solucionado seis vulnerabilidades en IBM Security Directory Server que podrían permitir a atacantes remotos autenticados ejecutar comandos arbitrarios, a usuarios remotos obtener información sensible y realizar ataques de cross-site scripting y a usuarios locales obtener información.

IBM Security Directory Server, anteriormente conocido como IBM Tivoli Directory Server, es un software de gestión de identidad de IBM basado en tecnología LDAP (Lightweight Directory Access Protocol), que proporciona una infraestructura de datos de identidad de confianza para la autenticación. Soporta plataformas IBM AIX, i5, Solaris, Windows, HP-UX...

El primero de los problemas corregidos (con CVE-2015-1978) reside en una vulnerabilidad de cross-site scripting. Un segundo problema (con CVE-2015-1972) podría permitir a un atacante remoto obtener información sensible a través de los logs de error. Un usuario local podría subir y descargar archivos cifrados potencialmente sensibles (CVE-2015-1959).

Por otra parte, la herramienta de administración web podría permitir a un usuario local autenticado ejecutar comandos que de forma habitual no debería tener acceso (CVE-2015-1974). Algunas páginas SSL pueden ser guardadas en caché lo que podría permitir a un atacante local obtener información sensible (CVE-2015-2019).

Por último, con CVE-2015-2808, corrige la vulnerabilidad conocida como "Bar Mitzvah Attack" que reside en el uso de RC4 con claves débiles en los protocolos TLS y SSL, lo que podría permitir a un atacante obtener información sensible. Un atacante remoto podría emplear esta vulnerabilidad para exponer credenciales de usuarios sin necesidad de realizar un ataque de hombre en el medio.

Se han publicado actualizaciones para corregir estos problemas para las versiones 6.0 a 6.4:

Más información:

Security Bulletin: Multiple Vulnerabilities fixed in IBM Security Directory Server



Antonio Ropero

Twitter: @aropero

domingo, 28 de junio de 2015

Actualización del kernel para Red Hat Enterprise Linux 7

Red Hat ha publicado una actualización del kernel para toda la familia Red Hat Enterprise Linux 7 que solventa siete nuevas vulnerabilidades que podrían ser aprovechadas por atacantes para provocar denegaciones de servicio, obtener contenido de la memoria o elevar sus privilegios en el sistema .

Un problema en la lectura y escritura de tuberías podría dar lugar a una corrupción de memoria que podría permitir a un atacante provocar condiciones de denegación de servicio o elevar sus privilegios en el sistema (CVE-2015-1805). Una condición de carrera en el subsistema de administración de llaves puede causar la caída del sistema (CVE-2014-9529). Una elevación de privilegios por un fallo en la implementación de la emulación 32 bits del kernel de Linux (CVE-2015-2830).

Un fallo en la implementación del sistema de archivos ISO podrá permitir a un atacante con acceso físico al sistema provocar un bucle infinito en el kernel, con la consiguiente denegación de servicio (CVE-2014-9420). Una fuga de información en la implementación del sistema de archivos ISO9660 podrá permitir a un atacante con acceso físico al sistema obtener hasta 255 bytes de la memoria del kernel (CVE-2014-9584). Una denegación de servicio local en la implementación de tablas netfilter por un error en la función nft_flush_table() (CVE-2015-1573). Por último, un desbordamiento de entero en la forma en la que el kernel de Linux aleatoriza el stack para procesos en determinados sistemas 64 bits (CVE-2015-1593).

Además se han solucionado otros fallos de menor importancia. Detalles sobre la aplicación de ésta actualización se encuentran disponibles en:

Más información:

Important: kernel security and bug fix update



Antonio Ropero

Twitter: @aropero

sábado, 27 de junio de 2015

Vulnerabilidad en Android permite acceder al contenido de la memoria

Investigadores de Trend Micro han anunciado una vulnerabilidad en Debuggerd, el depurador integrado en Android, que podría permitir acceder al contenido de la memoria de dispositivos con Android 4.0 (Ice Cream Sandwich) a 5.0 (Lollipop).

El problema reside en que a través de un archivo ELF (Executable and Linkable Format) específicamente creado podría dar lugar a la caída del depurador y exponer el contenido de la memoria a través de archivos tombstones y los correspondientes archivos logd. El ataque por sí mismo no sirve de mucho, salvo para realizar denegaciones de servicio, aunque sí podrá ayudar para la realización de otros ataques o exploits, que permitan la ejecución de código y evitar la protección ASLR.

Aunque el impacto inicial quede limitado, una aplicación reempaquetada o descargada en el dispositivo podrá explotar esta vulnerabilidad; que afecta a dispositivos Android 4.0 (Ice Cream Sandwich) hasta 5.x (Lollipop).

Principalmente la vulnerabilidad reside en que Debuggerd usa "sym->st_name" como offset para un comando de copia de cadenas sin comprobación de errores. Este valor puede ser controlado de forma sencilla por el ELF manipulado de forma que el valor del offset apunte a memoria inaccesible, lo que provoca la caída de Debuggerd.

Trend Micro reportó el problema a Google el pasado 27 de abril, que lo confirmó al día siguiente calificándolo como de gravedad baja. Se incluyó una actualización en el código del Android Open Source Project (AOSP) el 15 de mayo. También se ha confirmado que la vulnerabilidad quedará resuelta en la próxima versión, Android M.

Más información:

Trend Micro Discovers Android Vulnerability that Can Lead to Exposure of Device Memory Content


Antonio Ropero
Twitter: @aropero



viernes, 26 de junio de 2015

Claves SSH por defecto en dispositivos Cisco

Cisco ha publicado actualizaciones para sus dispositivos Web Security Virtual Appliance (WSAv), Email Security Virtual Appliance (ESAv) y Security Management Virtual Appliance (SMAv) después de encontrar que incluían claves SSH por defecto.
 
En esta ocasión son tres los dispositivos afectados:
  • Cisco Virtual Web Security Appliance (WSAv)
  • Cisco Virtual Email Security Appliance (ESAv)
  • Cisco Virtual Security Management Appliance (SMAv)
Que incluyen en dos tipos de claves SSH por defecto. 

El primero de los problemas se debe a la inclusión de una llave SSH autorizada por defecto que es compartida en todas las instalaciones de WSAv, ESAv y SMAv. Un atacante podrá explotar la vulnerabilidad obteniendo la llave privada SSH y empleándola para conectar a cualquier a cualquier dispositivo afectado con privilegios de "root".

Por otra parte, también incluyen llaves de host SSH por defecto compartidas, igualmente, en todas las instalaciones de WSAv, ESAv y SMAv. Un atacante podrá obtener una de las llaves privadas SSH y emplearla para descifrar o falsificar la comunicación entre los dispositivos afectados.

Cisco ha publicado actualizaciones para los tres productos afectados. El parche borrará todas las llaves SSH preinstaladas en el dispositivo, tras lo cual se indicarán los pasos precisos para completar el proceso.  La actualización está disponible mediante el proceso de actualización habitual. Aparecerá como "cisco-sa-20150625-ironport SSH Keys Vulnerability Fix" y se debe instalar de forma manual empleando CLI.

Una vez más vuelve a pasar, un dispositivo o software incluye algún tipo de clave o contraseña por defecto "oculta" y que puede permitir a un atacante remoto que la conozca tomar el control del sistema afectado. No es la primera vez que le pasa a Cisco, pero tampoco es el único fabricante al que le ha pasado. Anteriormente, productos como Cisco TelePresence Recording Server, Cisco NetFlow Collection Engine o Cisco Wireless Location Appliances también incluyeron cuentas administrativas con contraseñas por defecto.

Más información:

Multiple Default SSH Keys Vulnerabilities in Cisco Virtual WSA, ESA, and SMA

una-al-dia (31/07/2011) Contraseña por defecto en Cisco TelePresence Recording Server

una-al-dia (13/10/2006) Contraseña por defecto en Cisco Wireless Location Appliances

una-al-dia (26/04/2007) Credenciales por defecto en Cisco NetFlow Collection Engine
http://unaaldia.hispasec.com/2007/04/grupo-de-parches-de-abril-para-diversos.html


Antonio Ropero
Twitter: @aropero



jueves, 25 de junio de 2015

Rubygems, no todas las gemas son piedras preciosas

RubyGems.org es un repositorio centralizado de distribución de paquetes o gemas del lenguaje de programación Ruby, inspirado, como otros, en el CPAN de Perl. La idea es facilitar a los usuarios la descarga e instalación de librerías adicionales a las denominadas estándar. Este tipo de repositorio puede llegar a alojar miles de paquetes, y en diferentes versiones, haciendo que la búsqueda y despliegue de funcionalidad complementaria sea tremendamente sencilla, basta, en la mayoría de los casos, una simple orden de línea de comandos para reunir todo el proceso de descarga, extracción e instalación en una sola línea.

¿Qué lleva una 'gema' en sus entrañas?

Un paquete Ruby o gema no es más que un archivo comprimido con extensión .gem. Este archivo contiene el código Ruby y archivos con metadatos que describen la gema, hashes de integridad, etc., y opcionalmente una clave pública si ha sido firmada, algo que es completamente opcional.

El método de creación-distribución también es sencillo. Un desarrollador solo tiene que crear el paquete y subirlo al repositorio, la firma como hemos comentado es opcional. Esto ya de por sí es una solución de compromiso. ¿Creamos un repositorio donde cada desarrollador ha de certificarse y todas las gemas han de estar impecablemente firmadas o por el contrario "esto-es-la-guerra-más-madera"? Por supuesto siempre está la opción de autogenerar un certificado y firmar con él, pero esto nos lleva al eterno problema de la cadena de confianza. No porque algo esté firmado podemos darlo por goodware, es el origen el que estamos comprobando. Ya sea por una u otra razón los administradores de RubyGems optaron por la madera.

En referencia al firmado de gemas:

"However, this method of securing gems is not widely used. It requires a number of manual steps on the part of the developer, and there is no well-established chain of trust for gem signing keys".

Solo nos va a servir cuando queremos verificar el origen de un desarrollador concreto en el que confiamos. ¿Cómo confiamos en diez mil desarrolladores concretos?

Ojo, esta carencia de firmas y certificados no es única de RubyGems. Lo comentado podría hacerse extensivo a muchos más lenguajes de programación con sus respectivas plataformas de distribución.

Instalar una gema es trivial ('gem' es un comando incluido en la gema 'RubyGems'):

$ gem install <nombre>

Los usuarios de Linux y sistemas operativos con similares sistemas de distribución reconocerán al instante la familiaridad con las órdenes respectivas de instalación de paquetes. No es coincidencia, básicamente el patrón es el mismo.
Aquí vienen los problemas

Brandon Myers y Jonathan Claudius de SpiderLabs encontraron un juego de problemas en el canal de distribución, que hacen posible la interceptación e inyección de código malicioso en el proceso de instalación de gemas. Comencemos.

Aunque el comando 'gem' del sistema posea un repositorio sobre una canal seguro:

$ gem sources

*** CURRENT SOURCES ***


Cuando se va a instalar una gema el comando va a preguntar al servidor DNS de rubygems.org (o algún otro servidor agregado en 'sources') donde está el servidor encargado de servir las gemas y ciertas llamadas a una API relacionada. Esto se efectúa mediante una consulta SRV al servidor DNS, en este caso:

dig _rubygems._tcp.rubygems.org SRV +short

y la respuesta:

0 1 80 api.rubygems.org.

Como es evidente, la consulta DNS no va por un canal cifrado, esto permite a un atacante, interceptar la consulta y devolver una respuesta manipulada a un dominio controlado por el, por ejemplo: api.servidormalicioso.org.

El cliente 'gem' no comprobaba si la respuesta obtenida contenía otro dominio diferente a 'rubygems.org'. Es decir, si el origen es rubygems.org una respuesta NO VALIDA sería api.servidormalicioso.org. Sin embargo, hasta ahora, el 'gem' se tragaba la respuesta dándola por válida y dirigiéndose a este servidor para obtener acceso a la API, la propia gema y sus dependencias.

Es decir, el problema estriba en el cambio de dominio. Si 'gem' no permitiese dominios diferentes al establecido en 'sources', hubiese desechado 'api.servidormalicioso.org' como respuesta, que es la manera actual de funcionamiento tras el parche aplicado.

Esto abría el ataque a distintos vectores. Servir una gema troyanizada o una dependencia con una carga maliciosa ("reverse Shell", etc). En el video publicado por los investigadores a modo de demostración podemos ver un ejemplo bastante ilustrativo:
                                        https://vimeo.com/130781378

El lector atento habrá observado que la respuesta SRV contiene al puerto 80. Sin embargo 'gem' usará el mismo 'scheme' de la URI original de 'sources', esto es https, del otro modo seguiríamos siendo vulnerables al ser el tráfico plano.

Esta falta de comprobación tiene matricula: CVE-2015-3900 y ya ha sido corregida. Afecta a las versiones de RubyGems entre 2.0 y 2.4.6 (inclusive). Las versiones del lenguaje Ruby y librerías de la 1.9.0 a la 2.2.0 podrían contener una versión vulnerable de RubyGems.

Otro problema adicional que encontraron los investigadores fue con aquellas gemas que sí estaban firmadas.

Cuando procedemos a instalar una gema firmada le indicamos a 'gem' que compruebe el su firma. Previamente, por supuesto, deberemos tener el certificado público del desarrollador en nuestro repositorio.

'gem' dispone de varios niveles de comprobación de firmas, basados en políticas. La más estricta, 'HighSecurity' impide la instalación de una gema y sus dependencias si la firma no es correcta. El problema es que normalmente una sola gema tendrá asociada varias dependencias y esas dependencias pueden ser de lo más variopintas. Así las cosas, el usuario o administrador podrían relajar la política de seguridad y hacer una instalación con 'MediumSecurity', algo que ya de por sí suena mal (¿Seguridad a la mitad? ¿Medio seguro?).

MediumSecurity es una capitulación. Consiste en un "Bueno, comprueba al menos aquellas que sí están firmadas y las que no lo estén… pues haz la vista gorda". Esta relajación inhibe completamente la comprobación de origen de ciertos componentes abriendo la puerta, de nuevo, a su interceptación y manipulación maliciosa.

Problemas de confianza. En seguridad tenemos nuestro propio hombre del saco, se llama hombre en el medio, y si no desarrollas y despliegas infraestructuras pensando en él vendrá a por tu tráfico no cifrado, se lo comerá y no lo devolverá en forma de arcoíris maravilloso por el que desciende una manada de unicornios rosas elevando canticos celestiales.

Más información:

Attacking Ruby Gem Security with CVE-2015-3900

CVE-2015-3900 Request hijacking vulnerability in RubyGems 2.4.6 and earlier



David García
Twitter: @dgn1729

miércoles, 24 de junio de 2015

Actualización de Adobe Flash Player para evitar un 0-day

Adobe ha publicado una actualización para Adobe Flash Player para evitar una nueva vulnerabilidad 0-day que está explotándose en la actualidad y que afecta al popular reproductor. Esta vulnerabilidad podría permitir a un atacante tomar el control de los sistemas afectados.

Las vulnerabilidades afectan a las versiones de Adobe Flash Player 18.0.0.161 (y anteriores) para Windows y Macintosh, Adobe Flash Player 13.0.0.292 (y versiones 13.x anteriores) y Adobe Flash Player 11.2.202.466 (y anteriores) para Linux.

Esta actualización, publicada bajo el boletín APSB15-14, resuelve la vulnerabilidad con CVE-2015-3113 que según informa Adobe se está empleando actualmente en ataques dirigidos contra versiones anteriores de Flash Player. El problema reside en un desbordamiento de búfer que podría permitir la ejecución remota de código.

Los ataques han sido detectados por FireEye, identificando su autoría en un grupo de origen chino conocido como APT3 o UPS. Este grupo, ya conocido por otros exploits, está calificado por la compañía como uno de los grupos más sofisticados y con un amplio historial de nuevos exploits día cero basados en el navegador (Internet Explorer, Firefox o Adobe Flash Player).

Después de un ataque exitoso el grupo consigue rápidamente credenciales y lanza ataques adicionales e instala puertas traseras personalizadas. También se indica la dificultad de rastrear la infraestructura de Comando y Control (C&C) de APT3.

Adobe ha publicado las siguientes versiones de Adobe Flash Player destinadas a solucionar las vulnerabilidades, y se encuentran disponibles para su descarga desde la página oficial:
  • Flash Player Desktop Runtime 18.0.0.194
  • Flash Player Extended Support Release 13.0.0.296
  • Flash Player para Linux 11.2.202.468
Igualmente se ha publicado la versión 18.0.0.194 de Flash Player para Internet Explorer (10 y 11) y Chrome.

Más información:

Security updates available for Adobe Flash Player

Operation Clandestine Wolf – Adobe Flash Zero-Day in APT3 Phishing Campaign
  

Antonio Ropero
Twitter: @aropero

martes, 23 de junio de 2015

Actualización de seguridad para Google Chrome

Google ha publicado una actualización de seguridad para su navegador Google Chrome para todas las plataformas (Windows, Mac y Linux) que se actualiza a la versión 43.0.2357.130 para corregir cuatro nuevas vulnerabilidades.

Se ha corregido un error de validación de esquemas en WebUI (CVE-2015-1266), dos saltos de la política de mismo origen en Blink (CVE-2015-1267 y CVE-2015-1268) y un error de normalización en la lista precargada HSTS/HPKP (CVE-2015-1269).

Esta actualización está disponible a través de Chrome Update automáticamente en los equipos así configurados o a través de "Información sobre Google Chrome" (chrome://chrome/).

Más información:

Stable Channel Update



Antonio Ropero

Twitter: @aropero

lunes, 22 de junio de 2015

Vulnerabilidades en Cacti

Se ha publicado una nueva versión de Cacti (0.8.8d) destinada a corregir, entre otros problemas, varios fallos de seguridad. Estos errores permitirían a un atacante remoto realizar ataques de inyección SQL y de Cross-Site scripting.
 
Cacti es un software especialmente diseñado para crear gráficas de monitorización mediante los datos obtenidos por diferentes herramientas que emplean el estándar RRDtool. Es uno de los sistemas de creación de gráficas más empleado en el mundo de la administración de sistemas y puede encontrarse como parte fundamental de otros programas.

Los errores se detallan a continuación: 
  • CVE-2015-4342: Debido a un error de validación de entradas, un atacante remoto podría ejecutar comandos SQL en la base de datos subyacente a través de parámetros especialmente manipulados. El parámetro "cdef id" se encuentra relacionado con esta vulnerabilidad.
        
  • CVE-2015-2665: Se debe a un error al no filtrar correctamente código HTML proporcionado por el usuario. Un atacante remoto podría ejecutar código arbitrario en el contexto del usuario que lanza el navegador, lo que le permitiría obtener acceso a las cookies del usuario, incluidas las de autenticación. 
Se recomienda actualizar a la última versión 0.8.8d.

Más información:

Multiple vulnerabilities fixed in Cacti 0.8.8d


Juan Sánchez

domingo, 21 de junio de 2015

Actualizaciones de seguridad para Wireshark

Wireshark Foundation ha publicado dos boletines de seguridad que solucionan otras tantas vulnerabilidades en la rama 1.12.

Wireshark es una popular aplicación de auditoría orientada al análisis de tráfico en redes, que soporta una gran cantidad de protocolos y es de fácil manejo. Además Wireshark se encuentra bajo licencia GPL y disponible para la mayoría de sistemas operativos Unix y compatibles, así como Microsoft Windows.

Todos los errores de seguridad corregidos podrían llegar a provocar condiciones de denegación de servicio mediante la inyección en la red de paquetes maliciosos o bien engañando al usuario para que cargue ficheros de captura de tráfico de red manipulados. En esta ocasión las vulnerabilidades residen en los disectores 'WCCP' y 'GSM DTAP'.

Las vulnerabilidades se han solucionado en la versión 1.12.6 ya disponible para su descarga desde la página oficial del proyecto.

Más información:

wnpa-sec-2015-19 · WCCP dissector crash

wnpa-sec-2015-20 · GSM DTAP dissector crash


Antonio Ropero
Twitter: @aropero

sábado, 20 de junio de 2015

Vulnerabilidades en Symantec Endpoint Protection

Symantec ha confirmado tres vulnerabilidades en Symantec Endpoint Protection que podrían permitir a un usuario remoto autenticado realizar ataques de inyección SQL y a usuarios locales elevar sus privilegios en el sistema o crear condiciones de denegación de servicio.

Endpoint Protection es una suite de seguridad que engloba protección antivirus y cortafuegos corporativo. Ofrece seguridad tanto para servidores, estaciones de trabajo o entornos virtuales. Es un producto multiplataforma que cuenta con una consola para su administración de forma remota.

El primero de los problemas, con CVE-2014-9229, podría permitir a un usuario autenticado realizar ataques de inyección SQL ciega sobre algunos scripts de la consola de administración. Por otra parte, una denegación de servicio local debido a una condición de bloquo mutuo ("deadlock") en 'sysplant.sys' que incluso impedirá reiniciarse al sistema, lo que hace necesario apagarlo y arrancarlo por hardware (CVE-2014-9228).

Por último, una vulnerabilidad debido a inadecuadas restricciones en las rutas de carga de dlls podrá permitir la carga de dlls desde otros directorios. Un usuario local podrá situar una dll específicamente creada en alguno de los directorios afectados, de forma que posteriormente Endpoint Protection podrá cargar la dll maliciosa con privilegios del sistema (CVE-2014-9227).

Symantec ha publicado Endpoint Protection (SEP) 12.1.6 que soluciona los problemas.
Symantec Endpoint Protection Manager 12.1 RU6 está disponible desde Symantec File Connect.

Más información:

Security Advisories Relating to Symantec Products - Symantec Endpoint Protection Manager and Client Issues


Antonio Ropero

Twitter: @aropero

viernes, 19 de junio de 2015

Actualizaciones de seguridad para Adobe Photoshop y Bridge

Adobe ha publicado dos boletines de seguridad para corregir un total de cuatro vulnerabilidades en sus productos Adobe Photoshop CC y Adobe Bridge CC para las plataformas de Windows y Macintosh.

Los boletines han sido identificados como APSB15-12 y APSB15-13. El primero relacionado con el popular Adobe Photoshop, está afectado por las cuatro vulnerabilidades corregidas, y el segundo, orientado a Adobe Bridge, que está afectado por tres de las cuatro vulnerabilidades anunciadas.

Las vulnerabilidades en cuestión han sido identificadas con los CVEs correlativos que abarcan desde el CVE-2015-3109 hasta el CVE-2015-3112 y han sido calificadas como críticas. Debido a que todas las vulnerabilidades podrían permitir la ejecución de código arbitrario en la máquina afectada.

La vulnerabilidad CVE-2015-3109, que solo afecta al producto Adobe Photoshop CC, ha sido descubierta por Jeremy Brown, un investigador de seguridad de Microsoft, y se debe a una corrupción de memoria.

Las tres vulnerabilidades restantes, CVE-2015-3110, CVE-2015-3111 y CVE-2015-3112 afectan a los dos productos mencionados y han sido descubiertas por el investigador Francis Provencher de Protek Research Labs. Podrían causar un desbordamiento de enteros, una corrupción de memoria y un desbordamiento de memoria intermedia respectivamente.

Adobe recomienda que el usuario actualice sus productos con la máxima brevedad posible por medio de los mecanismos de actualización de las aplicaciones.

Más información:

Security update available for Adobe Photoshop CC

Security update available for Adobe Bridge CC



Jose Ignacio Palacios Ortega

jueves, 18 de junio de 2015

Cajas rotas, arena derramada

Un grupo de investigadores de varias universidades estadounidenses y chinas, ha publicado un interesante estudio en el que muestran los resultados de las pruebas a las que han sometido el modelo de aislamiento de procesos de Apple. Los resultados son cuanto menos inquietantes, no solo por el hecho de la demostración en la que pudieron acceder al llavero del sistema y llevarse un buen botín, sino que fueron capaces de evadir el estricto proceso de aprobación de la App Store, publicando una aplicación que era capaz de romper el aislamiento entre aplicaciones y acceder, o abusar del acceso, a recursos privilegiados.

El modelo de seguridad basado en "sandbox" no es nuevo ni exclusivo de Apple, obviamente. Desde hace ya bastante tiempo se intuyó la necesidad de separar, más aun, los procesos, incluso aquellos que compartían privilegios y propietario. De esta forma se protegen de manera más granular los recursos propios de cada aplicación. El sistema, pensado en principio para limitar programas en etapas experimentales que pudieran desestabilizar el sistema, servía también para contener y aislar el impacto de un proceso malicioso, impidiendo o dificultando su "onda expansiva".

Existen múltiples aproximaciones y diferentes implementaciones del modelo de sandboxing ("¿Cajarenización?"). Android, por ejemplo, asigna un UID de usuario distinto a cada aplicación y corre esa aplicación bajo ese usuario. Un uso curioso, quizás perverso en cuanto a costumbres, del modelo de permisos basado en usuario de Unix donde es habitual que ciertos procesos tengan usuario propio, pero solo unos pocos. Los recursos compartidos del sistema, esos que requieren permisos del usuario al instalar la aplicación, se administran a través de grupos. Toda aplicación o librería por encima del kernel Linux de un sistema Android corre bajo esta premisa. El componente que permite el sandboxing de procesos corre en espacio del kernel, por lo que muchas técnicas de evasión pasan por explotar una debilidad o vulnerabilidad en dicho espacio. No podemos evitar mencionar la utilidad de esta clase de arquitectura en el análisis dinámico de malware, apoyado en la virtualización de sistemas completos, dotando al analista de una herramienta sin par cuando necesita evaluar un conjunto de muestras de manera masiva.

Como todo sistema, como todo producto que lleve la consigna de la seguridad va a ser objeto de revisión por parte de la comunidad. La evasión de sandboxes no es noticia. En cada edición de Pwn2Own podemos ver como caen sistemáticamente las sandbox de los navegadores, la de Android ha sido desencajada varias veces a través de múltiples tipos de vulnerabilidades. Pon una puerta acorazada con una cerradura de última tecnología y cuando te des la vuelta tendrás a un señor en camiseta negra con un PowerPoint explicándote como la abrió de manera trivial. Nada nuevo bajo el sol.

En esta ocasión, no solo ha sido la evasión de este modelo en los sistemas operativos, cada vez más convergentes, de Apple. Ya de por sí, el hecho de que una aplicación consiga acceder a los recursos de otra aplicación resulta grave, ver esa aplicación publicada en el App Store es un hecho que deshace el componente diferenciador de Apple respecto a los mercados de aplicaciones. El control de aquello que se publica. Esa es la confianza que deposita el usuario cuando se decide a descargar e instalar una aplicación.

En palabras de los propios investigadores:

"Our research leads to the discovery of a series of high-impact security weaknesses, which enable a sandboxed malicious app, approved by the Apple Stores, to gain unauthorized access to other apps’ sensitive data"

y más adelante:

"Note that all our attack
apps were uploaded to
the Apple App Stores
"
Han demostrado que es posible subir una aplicación a la App Store capaz de acceder a recursos para la cual no estaba autorizada. Recursos que no deberían ser compartidos entre la aplicación gestora y el resto.

Bien, ya tenemos una aplicación maliciosa en el sistema ¿Cómo lo hace?

No se trata de explotación de vulnerabilidades al estilo de desbordamientos o punteros caídos en desgracia. Son fallos de diseño, de un diseño quizás excesivamente despreocupado, quizás por la presencia de componentes de seguridad como la sandbox. Creer que el sistema va a asumir el rol de guardaespaldas de todos los procesos es una temeridad. Es como desarrollar una aplicación en C pretendiendo que un hipotético sistema antiexploits cubra el riesgo de una gestión de memoria deficiente.

Acceso a los ítem de otra aplicación del llavero del sistema

El llavero del sistema, aunque no forma parte estrictamente de la sandbox, se comporta de manera similar, incluso desde el punto de vista de las aplicaciones la gestión de los recursos allí almacenados es parecida. En principio el llavero del sistema solo da acceso a las entradas guardadas por una misma aplicación, sin embargo es posible, cuando se crea una entrada, agregar otras aplicaciones al estilo de una lista de control de acceso.

Si una entrada en concreto no está creada cuando la aplicación legítima solicita su uso se consulta su existencia y si no existe se procede a su creación. El ataque se basa en la posibilidad de crear esta entrada por una aplicación maliciosa ANTES de que esta sea creada por la legítima. Cuando la aplicación maliciosa crea la entrada agrega a la legítima a la lista de aplicaciones autorizadas para acceder a ese llavero. Posteriormente, si el usuario instala dicha aplicación legítima, su entrada ya habrá sido creada adrede. Cuando se introduzca, por ejemplo, una contraseña, esa entrada seguirá siendo propiedad de la aplicación maliciosa y podrá acceder al contenido para robarla. La aplicación legítima seguirá creyendo que la entrada es suya, debido a que el sistema le permite el acceso al haber sido agregada por la maliciosa. Ingenioso.

BID conflictivos

Las aplicaciones en un Mac se presentan en un paquete de aspecto homogéneo pero en realidad son carpetas que contienen una jerarquía de archivos con sus recursos, ejecutables y bibliotecas. Cuando se genera una aplicación se asigna un identificador denominado BID. Este identificador ha de ser único a ojos de la App Store para que la aplicación sea aprobada, requisito, uno de muchos, indispensable.

Este BID también lo poseen los recursos integrados y portados por la aplicación, por ejemplo, ciertos ejecutables o conjunto de bibliotecas (denominados "frameworks" en Mac) necesarios para la aplicación principal, este tipo de recursos se denominan ‘sub-targets’.

Como dijimos, Apple inspecciona el BID de la aplicación principal, pero no efectúa esta comprobación en los mencionados 'sub-targets'. Esto permite a un atacante asignar el BID de un 'sub-target' de otra aplicación sin que esta incongruencia sea detectada. Cuando la aplicación maliciosa es ejecutada gana acceso a los recursos de la aplicación legítima. Por ejemplo, los investigadores ganaron acceso a los recursos de programas como Evernote, WeChat, QQ, etc.

Secuestro de WebSockets locales

Otro ataque que se basa en el esquema de pillería lazarillesca. Determinadas aplicaciones poseen un esquema cliente-servidor usando WebSockets a modo de comunicación IPC, desde una extensión en el navegador web a un servidor local ejecutado por la aplicación.

En las pruebas realizadas sobre la aplicación 1Password (gestor de contraseñas con integración en el navegador), pudieron constatar que no se efectúa una identificación del servidor a la escucha, la extensión de 1Password del navegador creía estar hablando con su contraparte en el sistema.

El resultado fue que todas las contraseñas se enviaban a una aplicación maliciosa que se encontraba a la escucha. Es decir, si se consigue ejecutar antes la aplicación maliciosa, esta se anticipa tomando el control del puerto acordado entre extensión-servidor. No hay forma de que la extensión compruebe si el servidor a la escucha es o no legítimo. No se trata de un fallo exclusivo de 1Password, el ataque es extensible a toda aplicación que use un esquema similar.

Secuestro de esquemas URL

Como sabemos, ciertas aplicaciones registran un 'handler' o esquema URL para facilitar la gestión de ciertos tipos de recursos. Así por ejemplo, si en el sistema, el esquema 'ftp://' está registrado por una determinada aplicación, cuando abramos una URL el sistema ejecutará la aplicación responsable de gestionar ese recurso y le pasará la URL.

En este caso _y visto lo visto_ el ataque se basa de nuevo en la anticipación en la toma de un recurso, en este caso las pruebas se hicieron registrando el esquema URL "wunderlist://" con el objeto de ser gestionado por una aplicación maliciosa. Wunderlist es una aplicación para la gestión de listas de tareas.

Cuando el usuario se autentifica es redirigido a través de una URL del tipo "wunderlist://". El problema es que esta URL contendrá un token secreto con la sesión del usuario, susceptible de ser interceptado para secuestrar la sesión activa del usuario.

Este mismo ataque es extensivo a aplicaciones como Pinterest o Facebook, las cuales usan un concepto similar de integración en el sistema.

XARA

Con el propósito de determinar qué tipos de aplicaciones contienen esquemas de funcionamiento similares a los descritos, los investigadores crearon una serie de herramientas para señalar aquellas que podrían ser objeto de alguno de estos ataques. El resultado fue demoledor: De 1.612 aplicaciones, el 88.6% es vulnerable a alguno de los ataques de este tipo.

El conjunto de ataques es denominado por los investigadores como XARA. (Unauthorized Cross-App Resource Access). En el documento publicado detallan las contramedidas y una propuesta de mitigación para solucionar posibles abusos mientras el fabricante toma medidas para paliar estas debilidades

Cajas rotas, arena derramada

Como hemos podido comprobar, no se trata de vulnerabilidades o fallos de programación. Son fallos de diseño, debilidades, excesos de confianza y la temible falsa sensación de seguridad. El hecho de que tu aplicación se ejecute en un entorno protegido, aislado o confinado no significa que un vecino listo no sepa arreglárselas para saltar la valla y fisgonear en tus dominios. Programación defensiva y pesimista. En desarrollo cobra valor la máxima: Si algo puede salir mal, no va a salir mal, probablemente saldrá bastante peor de lo que imaginas.

Más información:

Unauthorized Cross-App Resource Access on Mac OS X and iOS




David García
Twitter: @dgn1729

miércoles, 17 de junio de 2015

Vulnerabilidad en el teclado SwiftKey

NowSecure ha publicado una noticia alertando de un problema de seguridad en el teclado SwiftKey, un teclado que viene instalado en los dispositivos Samsung Galaxy desde la versión S4.

La vulnerabilidad fue descubierta por el investigador de seguridad Ryan Welton, investigador de seguridad de NowSecure, en diciembre del año pasado, cuando se informó a las compañías afectadas, Samsung y Google.

El problema se debe a que las peticiones que realiza la aplicación de teclado SwiftKey en busca de nuevas actualizaciones de diccionarios de lenguaje se realizan en texto plano a través de la red, peticiones que pueden ser falsificadas por medio de un ataque de hombre en el medio.

La vulnerabilidad en cuestión está identificada con el CVE-2015-2865 y calificada con un riesgo alto, puesto que este error puede ser explotado de forma remota para ejecutar código arbitrario con privilegios SYSTEM. Entre otros impactos, la compañía destaca las siguientes posibles acciones que un atacante podría tener en un dispositivo afectado: 
  • Tener acceso a todos los sensores.
  • Instalar aplicaciones sin el consentimiento del usuario.
  • Recoger registros del sistema.
  • Recoger registros de las aplicaciones instaladas.
  • Acceder a cualquier archivo personal.
El investigador de seguridad ha publicado en su canal de YouTube un vídeo en el cual puede apreciarse como aprovecha la vulnerabilidad.

Actualmente, ya existe una actualización en GooglePlay del teclado SwiftKey que corrige este error tan grave. Así mismo, en muchos dispositivos Samsung también se ha corregido la vulnerabilidad.

Más información:

Samsung Keyboard Security Risk

SamsungKeyboardExploit (video)

Aplicación Teclado SwiftKey + Emoji




Jose Ignacio Palacios Ortega


martes, 16 de junio de 2015

Google recompensará por encontrar vulnerabilidades en Android

La preocupación de Google por la seguridad es algo conocido. En esta ocasión, promueve una nueva iniciativa para intentar mejorar su sistema operativo para móviles: un programa de recompensas por encontrar y comunicar responsablemente vulnerabilidades en Android. 

Realmente Google cuida bastante la seguridad de sus productos, basta con ver la frecuencia de actualizaciones de Google Chrome. Fruto de la colaboración con la comunidad de investigadores, Google ha corregido más de 1.000 vulnerabilidades en su navegador que han sido reconocidas con una cantidad superior al millón de euros, a través del programa de recompensa de vulnerabilidades de Google Chrome.

Esta política ha contribuido a hacer que Chrome sea más seguro. Sin duda con la misma idea, ha creado crea un nuevo programa de recompensas que bajo el nombre de Android Security Rewards pretende recompensar las contribuciones de los investigadores de seguridad que invierten su tiempo y esfuerzo en conseguir que Android sea más seguro.

A través de este programa la compañía de Mountain View pretende ofrecer recompensas económicas y el reconocimiento público de las vulnerabilidades descritas. Como es habitual, el nivel de recompensa se basa en la gravedad de las vulnerabilidades y aumenta si los informes ofrecidos tienen mayor calidad, incluyen código para reproducir el fallo, casos de prueba o parches.

Las cantidades de recompensa base son 2.000 dólares para vulnerabilidades críticas, 1.000 $ para las de gravedad alta, y 500 para las moderadas. Sin embargo, en función de la gravedad del problema, la calidad del informe, exploits, etc. Pueden llegar a subir hasta los 38.000 dólares.

En esta ocasión Google ofrece recompensas por las vulnerabilidades de seguridad descubiertas en las últimas versiones de Android disponibles para teléfonos y tabletas Nexus. En la actualidad esto cubre los Nexus 6 y los Nexus 9. No es compatible con otros programas de recompensas de Google

Las vulnerabilidades que pueden optar al programa incluyen fallos en el código AOSP, código OEM (librerías y controladores), el kernel, el TrustZone y módulos. Vulnerabilidades en otro código no Android, como por ejemplo el código que se ejecuta en el firmware del chipset, también pueden optar a recompensas si impactan a la seguridad de Android.

Evidentemente la comunicación y divulgación del fallo tiene que ser responsable. De forma lógica, consideran como plazo razonable para una divulgación pública de la vulnerabilidad 90 días, el mismo tiempo que da el Project Zero de Google para la divulgación de vulnerabilidades. Todos los detalles sobre este nuevo programa están disponibles en:

Más información:

Android Security Rewards Program Rules

una-al-dia (30/09/2014) Google eleva las gratificaciones por encontrar vulnerabilidades

Chrome Reward Program Rules



Antonio Ropero
Twitter: @aropero


lunes, 15 de junio de 2015

Denegación de servicio en Cisco IOS XR

Cisco ha confirmado una vulnerabilidad de denegación de servicio remota que afecta a dispositivos con Cisco IOS XR para Cisco CRS-3 Carrier Routing System.

El problema, con CVE-2015-0769, reside en el tratamiento inadecuado de paquetes IPv6 que incluyan cabeceras de extensión. Un atacante podría aprovechar esta vulnerabilidad mediante el envío de un paquete IPv6, incluyendo cabeceras de extensión, a un dispositivo afectado configurado para procesar tráfico IPv6.

Cisco ha publicado actualizaciones para evitar este problema:
    hfr-px-4.1.0.CSCtx03546.pie para versiones 4.1.0
    hfr-px-4.1.1.CSCtx03546.pie para versiones 4.1.1
    hfr-px-4.1.2.CSCtx03546.pie para versiones 4.1.2
    hfr-px-4.2.0.CSCtx03546.pie para versiones 4.2.0

Más información:

Cisco IOS XR Software Crafted IPv6 Packet Denial of Service Vulnerability


Antonio Ropero
Twitter: @aropero


domingo, 14 de junio de 2015

Cross-Site Scripting en Adobe Connect

Adobe ha publicado Adobe Connect 9.4 que soluciona dos vulnerabilidades de cross-site scripting.

Adobe Connect es una solución de conferencias web para reuniones, aprendizaje electrónico y seminarios Web. Hace posible el uso de soluciones de conferencias en múltiples dispositivos a través de tecnología web.

Adobe Connect 9.4 incluye correcciones de múltiples errores (no relacionados directamente con problemas de seguridad) y grupos de usuarios nuevos en diferentes áreas del producto.


Se ha proporcionado una prueba de concepto para CVE-2015-0343:
https://[objetivo]/admin/home/homepage/search?account-id=1&filter-rows=1&filter-start=0&now=yes&query=<a href="javascript:alert('XSS')">XSS </a>

Más información:

Adobe Connect Help /Adobe Connect 9.4 Release Notes

XSS vulnerability Adobe Connect 9.3 (CVE-2015-0343 )

Adobe Connect


Antonio Ropero

Twitter: @aropero