Apple tiene más CVE que cualquier producto Microsoft en 2015

El año 2015 ya es historia y nos ha dejado grandes cosas. Hoy traemos una estadística que puede sorprender a muchos escépticos. Tras realizar un recuento de CVE, vulnerabilidades en el año 2015, se ha publicado que Apple ha sido el sistema operativo con más Advisory del año. Esto lleva a que muchos se adentren en un titular fácil: "OS X es el sistema operativo más vulnerable". Este tipo de titulares deben ser manejados con mucho cuidado, ya que tener de más CVE no implica que seas el más inseguro. 

Según los detalles que se pueden sacar de los CVE, OS X, en todas sus versiones, tiene 384 avisos en 2015. El sistema operativo iOS tenía 375. Flash tiene 314. Windows se encuentra atrás en el ranking, y el peor producto de la gente de Redmond es Internet Explorer con 231 CVE. ¿Qué significa todo esto? Realmente poco. La estadística llevada a cabo no hace distinción entre la gravedad o criticidad de las vulnerabilidades de la lista. En otras palabras, no es lo mismo una vulnerabilidad que permite ejecutar código remoto en una máquina que otra que te permite obtener un leak. 

Figura 1: Exposición de los hechos en Twitter por SecuriTay

 

Existen muchos errores de seguridad mutiplataforma. Esto quiere decir que si una vulnerabilidad afecta a una plataforma, posiblemente también a la otra. SecuriTay comentaba mediante Twitter que la manera de contar los CVE no ayuda a mejorar la seguridad, pero la gente ama los números. Esto es algo que parece bastante real, ya que esta estadística no refleja la verdadera seguridad que aportan los sistemas o aplicaciones. Habría que evaluar los riesgos que suponían cada una de las vulnerabilidades encontradas en cada sistema y aplicación. Por ejemplo, mediante un Score como puede ser CVSS.

AppStore: Bugs de Filter Bypass & Persistent Invoice Vulnerability

Una nueva vulnerabilidad se ha publicado sobre la AppStore, el cual permite que se inyecte de forma persistente código, en forma de script. Tanto Apple iTunes como la AppStore toman el nombre del dispositivo, un iPhone o un iPad por ejemplo, para las compras de los usuarios. Existe la posibilidad de que un atacante remoto pueda manipular el valor del nombre del dispositivo cambiándolo por un pequeño código script malicioso. Cuando el usuario accede a la AppStore o a iTunes este código será ejecutado al recuperar el nombre del dispositivo, provocando que la inyección se ejecute.

Hay que tener en cuenta que este código es almacenado por Apple, por lo que la vulnerabilidad es persistente. Una vez que el usuario quiere realizar comprar un artículo en la AppStore o iTunes se encontrará que el procedimiento interno recoge el valor del dispositivo y lo muestra. Este valor puede ser un script el cual pueda conseguir ejecutar ciertas acciones, ya que al final se produce ejecución de comandos. El investigador que descubrió la vulnerabilidad fue Benjamin Kunz Mejri. 

Figura 1: Demostración de los bugs en AppStore

La vulnerabilidad puede ser explotada por atacantes remotos que envían email como Apple, es decir, puede ayudar a realizar phishing. La vulnerabilidad se encuentra presente en ambas partes, es decir tanto comprador como vendedor, tal y como puede verse en el video. El impacto de la vulnerabilidad es medio, ya que ha obtenido un CVSS de 5.8. La explotación requiere un privilegio bajo por parte del usuario, y de ocurrir esta explotación se puede realizar un secuestro de sesiones, realizar phishing de forma persistente o redirecciones a recursos externos. 

UDID+ 2.5: Mail Command Injection en la versión de iOS

UDID+ es una sencilla y pequeña aplicación que muestra por pantalla el UDID, el identificador único de dispositivo de iOS. Con este UDID se pueden hacer muchas cosas, como por ejemplo generar un ipa, binario de iOS, preparado para un dispositivo concreto y que pueda instalarse en dicho dispositivo sin necesidad de pasar por la AppStore. Todo esto gracias al provisioning profile.Como curiosidad, hablamos ya de que Apple blqouearía las apps que leyesen este elemento del dispositivo, pero como se puede ver en la AppStore la aplicación está disponible.

La herramienta recupera esta información y permite al usuario enviarlo por correo electrónico o copiarla al portapapeles para pegarlo en otra ubicación. Como veis la herramienta es sencilla, aunque maneja información sensible del dispositivo, ya que puede ser el primer dato de interés para llevar a cabo un ataque dirigido.  Un Command Inject ha sido descubierto en la aplicación UDID+ 2.5, la cual es la última que hay en la AppStore. La vulnerabilidad permite inyectar código malicioso a la aplicación. La vulnerabilidad está localizada en el valor del nombre de dispositivo de la función "send by mail". Atacantes con acceso local a la aplicación pueden manipular el valor del nombre del dispositivo para comprometer esta función. 

Figura 1: PoC de la vulnerabilidad

El riesgo de seguridad ha sido estimado en medio con un CVSS de 5.7, ya que es un ataque local y no remoto. No se necesita autorización para llevar a cabo el ataque, por lo que hace que el CVSS sea mayor. Para solventar el bug se deberá lanzar una actualización de la app haciendo una validación de dicho parámetro para evitar esto. En los últimos meses hemos ido viendo como van saliendo diversas vulnerabilidades para apps, y es que según el informe que publicó HP, un alto porcentaje de apps móviles son vulnerables. Como casos recientes recopilamos File OYO Manager & WiFi File Transfer, Grindr v2.1.1, la red social gay más famosa o el LFI en la app de PhotoWebsite 3.1. 

OYO File Manager & WiFi File Transfer: Múltiples 0days

Últimamente estamos publicado diversas noticias sobre fallos que aparecen en aplicaciones de la AppStore. Además, estas vulnerabilidades que se muestran suelen ser 0days ya que afectan a las últimas versiones de estos aplicativos que se encuentran en la AppStore. Hace unas semanas hablábamos de un 0day en la app de Grindr 2.1.1 con la que un usuario podia bypassear la autenticación de otro. La semana antes vimos un 0day en Photo Manager Pro 4.4 el cual permitía la ejecución de código arbitrario. Y cerrando el círculo de este último mes, comentamos un Local File Inclusion en PhotoWebsite 3.1.

Hoy hablamos de OYO File Manager en su versión 1.1, la cual presenta diversas vulnerabilidades que un atacante podría aprovechar, por ejemplo, para ejecutar comandos. La primera vulnerabilidad que se detalla en el documento publicado por Vulnerability Lab es la de un Local File Inclusion. La vulnerabilidad se encuentra en el valor filename del módulo de upload y permite acceder al contenido de otros archivos. El CVSS que se ha otorgado a esta vulnerabilidades es de 6.5. 

Figura 1: Local File Inclusion en OYO File Manager 1.1 para iOS

La segunda vulnerabilidad que se detalla en el documento publicado corresponde con un Command Injection. Hace poco en Seguridad Apple tratamos algún ejemplo de aprovechamiento de un Command Injection a través del gestor de correo nativo de iOS denominado Mail. El Command Injection ha sido detectado en el parámetro devicename en el módulo index. Un atacante podría inyectar su propio código malicioso y ejecutar comandos. Lo que resta, y mucho, valor al CVSS es que para llevar a cabo el ataque se tiene que tener acceso físico al dispositivo. El CVSS ha sido determinado en 5.6.

Figura 2: Command Injection en OYO File Manager 1.1 para iOS

La tercera vulnerabilidad que se detalla en el documento es un Remote Path Traversal. Esta vulnerabilidad cuenta con un CVSS de 6.9. Parece que estamos en un mes en el que las vulnerabilidades en apps están a la orden del día, seguiremos atentos a próximas publicaciones.

Local File Inclusion en la app PhotoWebsite 3.1 para iOS

En muchas ocasiones hemos oído hablar de la seguridad de los sistemas operativos y comparativos entre iOS, Android o BlackBerry. Cada vez son más los informes que se centran en las aplicaciones que corren sobre dichos sistemas, ya que en muchas ocasiones encontraremos los vectores de ataque en estas apps. Hoy traemos la noticia de un LFI encontrado en la app PhotoWebsite 3.1, la cual a día de hoy se encuentra en su última versión en la AppStore, por lo que no hay parche que solucione esto.

La aplicación monta un servicio con el que se puede acceder al contenido de las fotografías realizadas en el dispositivo. Se pueden subir fotografías al dispositivo y todo se gestiona a través de una contraseña. Como se dijo anteriormente, lo más grave es que a día de hoy la vulnerabilidad afecta a la última versión disponible de la aplicación. En el sitio web de Exploit-DB podemos encontrar el documento que habla sobre la vulnerabilidad. En este documento se detalla el CVSS, Common Vulnerability Scoring System, la fecha de liberación y los detalles técnicos para recrear la explotación de la vulnerabilidad, junto a una prueba de concepto.

Figura 1: LFI en PhotoWebsite obtenido en Exploit-DB

Con este LFI un atacante puede, de forma remota y no autorizada, leer información interna de la aplicación. El CVSS es de 6,6 ya que no se requiere interacción del usuario y es un ataque que puede llevarse a cabo de forma remota, aunque en la práctica no en Internet, ya que el dispositivo utilizará una red WiFi, ya que utilizando 3G u otro tipo de red no sería accesible, a priori

Java 8 Update 31 para OS X: Oracle lanza actualización crítica que contiene 169 nuevos parches de seguridad

El año no comienza del todo bien para la gente de Oracle y es que ayer lanzó una actualización crítica cuyo contenido tiene una colección de parches para múltiples vulnerabilidades de seguridad. Oracle ha ido recibiendo informes específicos de que su software iba siendo explotado, no solo centrándose en Java. Oracle ha comunicado que recomienda que sus clientes apliquen las actualizaciones necesarias sin dejar pasar el tiempo. 

El número de parches aplicado en esta actualización es de 169, siendo un número muy alto. Los productos afectados son muy variados, siendo esta información detallada por Oracle en su sitio web. Como ejemplo os dejamos un listado breve del software afectado Oracle Java SE y Embedded version, Oracle Virtual Box, SPARC Enterprise, Solaris, Oracle Database Server, etcétera. 

Figura 1: Actualización de Java en OS X

Si tienes Java instalado en tu OS X seguramente hayas visto un mensaje como el que se puede visualizar en la imagen. Se solventan 19 vulnerabilidades en Java, siendo 14 de éstas explotables remotamente sin autenticación. Existen 4 vulnerabilidades con un CVSS igual a 10, y 2 vulnerabilidades con CVSS de 9.3. Esto quiere decir que las vulnerabilidades son realmente críticas. Como recomienda Oracle actualiza urgentemente tu versión de Java y solventa los siguientes fallos de seguridad:

Figura 2: Listado de CVEs que afectan a Java

Visto lo visto, no tardes en actualizar tu Java y evita la ejecución de código arbitrario que estas vulnerabilidades traen consigo.

24 días después del update Apple da los CVE de seguridad

Esta es una historia de la que nos hemos quejado ya muchas veces, y de la que seguramente oiréis a más de uno que trabaje en seguridad, a la hora de hablar de Apple y cómo trata la información y las actualizaciones de sus productos. Os resumimos esta historia que tiene que ver con una actualización de Apple durante el mes de Agosto. Vamos con la cronología de los hechos.

El pasado 13 de Agosto Apple puso en circulación AirPort Base Station Firmware Update 7.6.4, una revisión del firmware que arreglaba unos issues que podían afectar al funcionamiento del sistema.

Figura 1: Información disponible de AirPort Base Station Firmware Update 7.6.4

Como es habitual en Apple, se hacía referencia a la página HT1222 donde se publica la información que tiene que ver con los bugs y los CVE de cada actualización - más o menos -, pero allí no había nada -. De hecho aún no hay nada. Siendo esto así que nosotros decidimos no priorizar esta actualización en nuestra lista de publicaciones y al final salió el día 26 de Agosto en Seguridad Apple.

Figura 2: Página HT1222 con información de actualizaciones de seguridad

Cuando parecía una vez más que no iba a salir publicada la información, resulta que Apple publicó el 6 de Septiembre, es decir, 24 días después de estar disponible el software, el Security Advisory APPLE-SA-2013-09-06-1 AirPort Base Station Firmware Update 7.6.4, donde se recoge la existencia del CVE-2013-5132 para provocar ataques D.O.S. en equipos con software sin actualizar.

Figura 3: Información del APPLE-SA-2013-09-06-01

Se supone que la información de los CVE asociadas a las actualizaciones de software se proporciona para que los equipos de trabajo en las empresas puedan priorizar el despliegue de nuevas versiones con respecto a otro trabajo evaluando la criticidad de la actualización. La publicación del software sin lista de CVEs habrá hecho que tenga una prioridad determinada en la cola de planificación de una empresa generando el CVSS asociado. Al publicar ahora por fin el Security Advisory las empresas se verán obligadas a volver a evaluar esa prioridad. Además, como gracieta, Apple sigue con su idea de que los viernes es el mejor día para publicar los advisories de seguridad.

Pero es que tan poca información hay en este caso sobre los CVE de esta actualización, que hoy 8 de Septiembre aún no se habían publicado los detalles del CVE-2013-5132 en la base de datos de seguridad del Mitre para saber exactamente qué versiones y que productos en concreto están afectados. ¿Son todos? ¿Todas las versiones anteriores? ¿Sólo algunos?

Figura 4: Información del CVE-2013-5132 en la base de datos del Mitre

Si alguien publica el exploit en breve, y estos dispositivos se usan en sitios críticos como en la comunicación de vagones de tren y estaciones o para controlar vía WiFi cualquier fábrica mediante envío de datos de importancia, podría provocarse un serio incidente. Alguien debería decirle a Apple que la seguridad es importante y que así no se hacen las cosas cuando se publican actualizaciones de software que solucionan CVEs de seguridad en ellas.

Apple Security Updates & Security-Announce Mailing List

Con el lanzamiento de cada nueva actualización de software desde Apple, los que trabajamos en seguridad intentamos conocer cuáles han sido los CVEs solucionados en ella. Es importante conocer estos para poder medir la criticidad de la actualización, algo que es fundamental para cualquier gestión de riesgos y seguridad dentro de una compañía.

El primer lugar en el que Apple publica los CVEs de seguridad asociados a cada actualización es la web, en el artículo de la knowledge base HT122 llamado Apple Security Updates. Este artículo se actualiza después de cada publicación de actualizaciones, pero por desgracia nunca se hace antes, y lo más probable es que aparezca la actualización y pase hasta un día antes de que estén disponibles allí todos CVE corregidos.

Figura 1: Artículo HT122 "Apple Security Updates"

Por otro lado, Apple utiliza el, aún muy común en el mundo de seguridad, sistema de las listas de correo electrónico, donde lanza los Security Updates con el detalle de los bugs corregidos en cada nueva revisión de sus productos. Entre las listas donde los envía está la suya propia, llamada Security-Announce Mailing List, y a la que te puedes suscribir por correo o por RSS para que te lleguen estos mensajes en cuanto Apple los libere.

Figura 2: Últimos Security Advisories enviados a Security Announce Mailing List

Si te gusta estar informado en el momento de estos temas puedes utilizar estos recursos, tal y como hacemos nosotros para que no se nos escape nada de lo que sucede en seguridad en la casa de la manzana mordida.

CVE Details: Buscar exploits para códigos CVE

El número de vulnerabilidades que se publican diariamente es altísimo, sin embargo, el número de exploits que se ponen disponibles no iguala ni por asomo al de vulnerabilidades y muchas veces no está en tu mano el exploit que necesitas para un bug no parchado. Frameworks como Metasploit son una herramienta básica para todo pentester, pero por desgracia no están todos los exploits del mundo.

Muchos de los exploits que tal vez necesites acaban sólo en frameworks comerciales, como Canvas de Immunity, ya que los desarrollan con sus equipos de exploiters y no son públicos. Por supuesto, antes abandonar el camino de explotar una vulnerabilidad por no estar en Metasploit debes revisar bien por Internet buscando información sobre ella, para ver si hay una POC en algún rincón que puedas usar o adaptar a tu entornos, y para ello, las bases de datos de expedientes CVE son fundamentales.  En ellas, en la parte de referencias aparece si hay algún exploit público, lo que subiría la severidad del bug en su valor CVSS, aparecerá enlazado.

Figura 1: Expedientes CVE de Apple por años

Para revisar la base de datos de expedientes de seguridad CVE la web de CVE Details puede serte de gran ayuda, ya que tiene un interfaz basado en un estilo de hoja de cálculo, que te permite navegar fácilmente por los expedientes CVE asociados a fabricantes de software y productos.

Figura 2: Expedientes CVE de Apple ordenados por existencia de exploit público

Además, por cada listado, puedes clasificar los expedientes CVE por criticidad del mismo, número de exploits públicos o fecha, lo que permite acceder a datos interesantes de manera muy rápida.

Figura 3: Expediente CVE-2010-1029

Lo mejor es que permite buscar por otros códigos de expedientes como los BID, los códigos de Microsoft y en todo momento enlaza con la base de datos de Metasploit para indicarte si existe un exploit asociado a ese CVE en el framework.

Figura 4: El expediente CVE-2010-1029 no tiene módulo en Metasploit

Si no está en Metasploit, no tienes porque abandonar ya que, como hechos dicho al principio, los expedientes CVE tienen asociadas las referencias a exploits en Internet, y puede que el que buscas esté en una web de exploits como Exploit-db, y lo puedas usar.

Figura 5: Referencias a exploits del CVE-2010-1029 públicos en Internet

En definitiva, CVE Details es un buen sitio para revisar los expedientes CVE de manera cómoda, ya que su estilo de hoja de cálculo hace muy cómodo acceder a información en detalle e información resumen mediante gráficas o listados de datos agrupados.

Criticidad de un Bug: Common Vulnerability Scoring System

Cada vez que aparece una actualización de un nuevo producto, como cuando Apple publica una nueva versión de uno de sus herramientas, todos los que trabajamos en seguridad informática vamos a comprobar los bugs arreglados y los que no. Cada bug recibe un código único en cada base de datos que es catalogado, aunque la más utilizada es la base de datos de expedientes de seguridad CVE (Common Vulnerabilities and Exposures).

Sin embargo, lo que queremos tratar hoy no es cómo se identifica el bug, sino qué mecanismos se utilizan para medir su importancia dentro de la seguridad de un sistema.

Common Vulnerability Scoring System v2

El mecanismo más popular que se usa para medir la criticidad de un bug se basa en el CVSS (Common Vulnerabilities Scoring System), que actualmente está en su versión 2. Este sistema de medición de la importación de un bug se basa en varios factores que tienen que ver con:

Métricas de explotabilidad

En este apartado se miden principalmente tres factores a tener en cuenta, como son  El vector de ataque, en el que se mide si el ataque es local, en red de area local o remotamente desde Internet. La complejidad del ataque, en el que se miden las circunstancias que tiene que darse para que crear un exploit consistente, es decir, si es complejo, medio o poco complejo hacer el explotar el bug.  El nivel de autenticación, donde se mide si es necesario contar o no con privilegios para la ejecución del exploit.

Métricas de Impacto

En este apartado se mide el impacto que tendría la explotación del bug en cuanto a la integridad, confidencialidad y disponibilidad del sistema, midiendo en cada una de ellas su valor de impacto.

Métricas de Entorno

En este caso se mide el impacto en una organización en concreto, utilizando modificadores generales, que miden el número de sistemas que se ven afectados por este bug y el porcentaje de daño que puede generar en ellos como modificadores de los factores de Integridad, Confidencialidad y Disponibilidad de este bug concreto en un entorno de empresa en particular.

Métricas Temporales

En ellas se mide el tiempo que tardará en aparecer un exploit para esta vulnerabilidad, el tiempo que tardará en aparecer un parche o solución para este bug, y el nivel de verificación de que esta vulnerabilidad efectivamente existe.

Calculadora CVSS 2

Para calcular el valor CVSS 2 de una determinada vulnerabilidad, se puede utilizar una calculadora, donde sólo se deben rellenar los valores conocidos para estos parámetros y se obtendrá un resultado. En nuestro ejemplo, el resultado ha sido un Highly Critical con un 4.5 sobre 5, en parte porque en la configuración se ha seleccionado la opción de que se ha comprobado la existencia de un exploit funcional.

Figura 1: Cálculo de criticidad de un bug ficticio

Cuando aparece un parche para un bug, la información sobre ese bug crece, lo que hace que el tiempo para sacar un exploit funcional se acorte. Es por eso la insistencia de todos los que trabajan en seguridad para aplicar las medidas de seguridad.

Éste no es el único sistema de medir el impacto de un bug, pero es uno de los más populares. En el futuro os traeremos algunos otros esquemas populares para medir la seguridad de una organización.