Nueva campaña de phishing dirigida a usuarios de iOS con autenticación en Facebook

Este mes se ha detectado una nueva campaña de phishing dirigida a los usuarios de iOS (pero facilmente replicable para dispositivos Android) . Esta campaña les solicita que inicien sesión con su cuenta de Facebook y así pueden obtener sus credenciales. Para llevar a cabo este ataque, la compañía Myki cuenta en el informe que los atacantes clonan los sitios web para engañar y atraer a las víctimas, una vez en el sitio los atacantes piden que se autentiquen con Facebook. Una vez autenticados, se verá un mensaje indicando que su cuenta se ha visto comprometida.

A continuación, se puede ver en el vídeo una PoC haciendo uso de un sitio falso de AirBnB.

Jebara cuenta que el ataque no está del todo bien implementado y contiene algunos defectos tanto: “El inicio de sesión con indicaciones de Facebook se presenta como una ventana externa en Safari, no como una pestaña adicional a la que el usuario cambia, ya que la URL de origen sigue apareciendo de forma minimizada en la barra de navegación falsa de Facebook". Pero avisa, los defectos comentados pasarán desapercibidos para la mayoría de los ojos, ya que las acciones serán familiares a los usuarios. Como mecanismo de protección para este ataque, Jebara indicó que usar un factor de autenticación múltiple o un administrador de contraseñas hubiese sido eficaz.

Como apps pueden rastrearte incluso después de desinstaladas

¿Alguna vez te ha pasado que después de desinstalar una aplicación has recibido algún correo o anuncio sobre ella?. Pues puede que no sea una coincidencia, o así es lo que comentan en Bloomberg , donde el pasado lunes escribieron un artículo que hablaba de como algunas empresas como Adjust, AppsFlyer, MoEngage, Localytics y CleverTap ofrecen un conjunto de herramientas para hacer un seguimiento intensivo del uso de aplicaciones, llegando al punto de ser capaces de notificar hasta cuando un usuario desinstala una aplicación.

El seguimiento y las analíticas del uso de una aplicación no es algo ni secreto ni nuevo, tanto Google con sus Google Analytics como Apple con Apple Connect recopilan determinadas acciones y comportamientos del usuario, que sirve para que los desarrolladores detecten bugs, mejoren sus aplicaciones y depuren la experiencia de uso de la aplicación. Todo esto se ciñe a las normas de las tiendas de aplicaciones, al final ni la Play Store ni la App Store impiden la recolección de datos, siempre que sea para la mejora de servicios y con una cierta anonimidad. Otra cosa es utilizar determinados servicios con fines publicitarios, cosa que estaría pasando con el seguimiento de aplicaciones desinstaladas.

El funcionamiento de esta librería es sencillo, un desarrollador haría uso de las llamadas notificaciones push silenciosas, elemento que permite hacer un ping a aplicaciones instaladas sin alertar al usuario. Gracias a la capacidad de ejecución de código en segundo plano, la aplicación mandaría de vuelta una notificación para verificar que sigue instalada y en el caso de que no haya retorno, notificaría que la aplicación se ha desinstalado. El problema de este procedimiento es que sí viola las reglas de las tiendas de aplicaciones de Apple y Google, ya que habría un registro exacto de usuarios identificados con la aplicación desinstalada.

Para ver si esto es cierto, vamos a proponer hacer una prueba de concepto, en la que un servidor lanzará una notificación push silenciosa a un dispositivo con una app instalada, con una pequeña librería que intentaría imitar el funcionamiento antes descrito.

Para ello, nos vamos a valer de los siguientes elementos:

• Un dispositivo iOS: La PoC no se puede realizar en un emulador ya que no soportan notificaciones push.
• Pertenecer al programa de desarrolladores de Apple: Para habilitar las notificaciones push, es necesario pagar para el programa de desarrolladores y habilitar la funcionalidad.
• Pusher. Pusher es una aplicación que podéis descargar aquí y sirve para enviar notificaciones push a dispositivos determinados, en la propia Wiki del proyecto aparece las instrucciones para configurar la aplicación y la app del destinatario.

Una vez tenemos todos los elementos, vamos a enumerar todas las tareas involucradas en el envío y procesamiento de notificaciones:

• Una app configurada correctamente y registrada con el Apple Push Notification Service (APNS) para recibir notificaciones push desde que el teléfono se encienda.
• Un servidor que envie las notificaciones push al APNS dirigido a uno o más dispositivos.
• Código dentro de la app que pueda ejecutar acciones una vez reciba la notificación utilizando el delegado de la aplicación.

Figura 1: Configuración de SSL de las notificaciones push

Para habilitar las notificaciones push hay que dirigirse dentro de Xcode a App Settings > Capabilities, y allí habilitar el campo de “Push Notifications”, así Xcode realizará todos los pasos necesarios para crear los certificados de la funcionalidad. Después de esto tendremos que ir a nuestra cuenta de desarrollador para crear un certificado SSL de desarrollo para poder mandar las notificaciones a nuestra aplicación. Una vez creado es necesario descargarlo y añadirlo a nuestra keychain. Ahora Pusher será capaz de enviar notificaciones a nuestro dispositivo.

Por último nos queda habilitar las notificaciones push silenciosas, para ello, y otra vez en App Settings > Capabilities, seleccionaremos dentro de "Background Modes" las opciones "Background Fetch" y "Remote Notificacions". Con esto podremos ejecutar código y enviar peticiones en segundo plano en nuestra app. Ahora solo sería necesario ejecutar la aplicación, recoger el token único identificativo que aparecen el log, introducirlo en la aplicación Pusher para enviar notificaciones.

Si hemos configurado la url de redirección bien a un servidor que esté activo y escuchando, deberíamos recibir una petición con el mail falso generado, cosa que se producirá si la aplicación no se encuentra en el dispositivo, generando así un registro de la eliminación de la app por parte del ususario.

Con el video de la prueba de concepto terminamos el artículo, como siempre dejamos el link al proyecto con el código de la aplicación.

Progressive Web Apps: Cómo instalar aplicaciones fuera de la App Store en iOS

El pasado 10 de Julio se celebró el décimo aniversario de la App Store, que comenzó oficialmente sus andadas con 500 aplicaciones en 2008. En estos diez años el crecimiento ha sido espectacular, llegando a cifras astronómicas de casi 2 millones de aplicaciones subidas, 20 millones de desarrolladores registrados e ingresos que superan los 100 mil millones de dólares americanos. Desde su lanzamiento, la App Store ha sido el único punto de instalación oficial de aplicaciones de terceros en dispositivos iOS, caracterizándose desde el principio por tener unas guías de estilo marcadas y un equipo de revisión encargado de asegurar que todas las aplicaciones presentes en ella cumplieran estas reglas.

Actualmente es difícil pensar en iOS sin su tienda de aplicaciones, aunque esto no fue siempre así. En 2007, Steve Jobs anunciaba un “One more thing” en la WWDC sobre como desarrollar aplicaciones para el iPhone original y, por raro que pueda resultar ahora, la forma original era crear Web Apps. La App Store no estaba en los planes originales del iPhone OS y la visión de Apple sobre las Web Apps no era más que aplicaciones web ejecutándose en la pantalla de inicio. Todo esto cambió el año siguiente con la aparición de aplicaciones nativas, relegando a las aplicaciones web a un segundo plano, en el que han permanecido hasta ahora.

El término Progressive Web App fue acuñado por Google en el evento I/O de 2017 y hace referencia a toda aplicación que combina las mejores características de la web y de aplicaciones nativas. Estas apps tienen algunas características en común, como la capacidad de funcionar offline o ser instaladas en un sistema operativo sin necesidad de compilarlas ni firmarlas. Para ello Chrome ha ayudado a desarrollar varias tecnologías que permiten llegar a esta experiencia como los Service Workers, que proporcionan persistencia en un navegador o los Web App Manifest, que otorgan una estructura lógica a los proyectos que implementan PWA.

Desde el 20 de Marzo de 2017 Apple lleva soportando estas tecnologías en Safari con iOS 11.3, poniéndose a la par con otros navegadores que ya lo implementaban como Chrome, Firefox, Samsung Internet, UC Browser y Opera. Este hecho es bastante inusual por ir en contra de uno de los principios básicos en iOS y explicaría por qué Apple no ha publicitado esta característica en su web de desarrolladores.

 

¿Significa que pueden instalarse aplicaciones en iOS sin pasar los test antes mencionados de la App Store? La respuesta corta es sí, desde hace unos meses es posible instalar aplicaciones nativas no aprobadas por la App Store. La respuesta completa, por otro lado, deja bastantes interrogantes y revela numerosas limitaciones en el uso de una aplicación web progresiva en iOS. Como se menciona antes, el método de instalación de una PWA no difiere al método de instalación de una Aplicación Web convencional. Solo es necesario abrir una página web habilitada, pulsar el botón de compartir y seleccionar la opción de “Añadir a pantalla de inicio” en el menú contextual. Aún siendo sencillo, iOS limita el uso de banners en la Aplicación Web para la auto-instalación de la misma, como sí permite Android.

PoC

Para demostrar lo sencillo que puede llegar a ser desarrollar una PWA y los potenciales peligros que implican su instalación vamos a crear una aplicación en Angular 6 que haga uso de Firebase y Material design. Esta aplicación permitirá a un usuario autenticarse, tomar fotos y visualizar un feed de imágenes con un título y descripción. De forma paralela se colocará un código “malicioso” que mandará la ubicación del usuario cada 30 segundos a una base de datos. Por otro lado, se desarrollará una segunda aplicación que se alimentará de esta base de datos para mostrar en un mapa la posición del usuario.  

Crear estas aplicaciones es bastante sencillo, primero hay que instalar npm y angular cli como se describe en la página oficial de Angular. En Angular 6, dar soporte a las PWA es tan sencillo como ejecutar ‘ng add @angular/pwa’, de forma similar incluir los paquetes de firebase y angular material es tan sencillo como ejecutar ‘ng add @angular/material’ y ‘npm install firebase angularfire2 --save’.  

Figura 1: Ejecución

Ahora es el momento de desarrollar las aplicaciones, creando todos los componentes y servicios necesarios para su funcionamiento, habilitando la conexión con firebase y la api de Google Maps para visualizar la localización del usuario. Una vez completo, solo sería necesario colocar el código que envíe la posición del usuario y subir a producción la PWA.

Figura 2: Código

Una vez publicado, solo es necesario que un usuario se registre en la aplicación, acceda a ella y empiece a publicar información. Cada vez que abra el componente del feed de imágenes enviará su posición cada 30 segundos. En las pruebas realizadas se confirma que el código no se ejecuta en segundo plano, no por ello con apenas sacar la aplicación una tarde en diferentes localizaciones para añadir imágenes al feed, se puede observar un mapa detallado con zonas frecuentes, siendo un dato sensible almacenado que no cumple ninguna funcionalidad.

Mabouia & Gopher: Ransomware para OS X. ¿Estás listo?

Todavía hay muchos usuarios de Windows que no tienen idea de qué es el Ransomware, a pesar de que muchos ya lo han sufrido con dureza en sus carnes. Si miramos hacia OS X, los usuarios no están nada avisados ni preocupados, y es de necios pensar que no habrá dentro de poco una campaña de Ransomware para OS X, así que más vale que tengas listas tus copias de seguridad, y que tengas fortificada tu plataforma al máximo, ya que si no, tendrás los mismos problemas que los usuarios de Windows que se han visto afectados por estos ataques.

Ya durante este año, el investigador brasileño Rafael Salema Marqués creó una Prueba de Concepto llamada Mabouia que demostraba lo sencillo que sería hacer un software malicioso tipo Ransomware para sistemas OS X.

Figura 1: Mabouia, primera PoC de Ransomware para OS X

Durante el pasado mes de Septiembre, otro investigador de seguridad, en concreto Pedro Vilaca, publicó el código de Gopher, otra Prueba de Concepto de cómo de cómo de sencillo sería hacer Ransomware para OS X. El código está disponible en Github.

Figura 2: Código fuente de Gopher, un ransomware para OS X

Viendo esto, el tiempo que va a pasar hasta que tengamos una campaña de Ransomware en OS X va a ser muy pequeño. Nuestras apuestas son que antes de fin de año tenemos la primera serie. ¿Estás listo para evitarla?

Crash en Apple Safari 8 en OS X 10.10.X Yosemite

Cada día salen nuevas vulnerabilidades en OS X y los productos de la gente de Apple. Esto es debido en parte a la cuota de mercado que están alcanzando, y en el interés generado por estudiar e investigar sus sistemas y aplicaciones. No hay que irse muy lejos para recordar la vulnerabilidad rootpipe en la que se consigue elevar privilegios y obtener una shell como root. Se espera que Apple ponga solución a esto en Enero de 2015.

La última versión de Apple Safari en OS X trae un fallo que produce el crash de la aplicación produciendo el cierre inesperado del navegador. Un posible atacante puede provocar el cierre de Apple Safari utilizando un enlace que lleve a la víctima a ejecutar el contenido que el atacante ofrece. En la imagen se puede visualizar el código necesario para provocar la caída del proceso, el cual puede ser descargado de sitios como exploit-db.

Figura 1: Código que provoca el crash de Safari 8 en OS X 10.10

Cuando la víctima accede al recurso malicioso compartido por el atacante, se puede leer en el navegador que el contenido web de Apple Safari se cierra inesperadamente. Si se abre el recurso con otro navegador web, esta situación no ocurre, por lo que según se indica en exploit-db este fallo solo ocurre en Apple Safari.

Figura 2: Crash de Safari

Cuando Apple Safari se cierra pide al usuario informar a Apple del error y en opciones más avanzadas podremos visualizar el volcado que se hace, el cual es muy similar al que se puede ver en exploit-db o 1337day. Al final esta vulnerabilidad no deja de ser un DoS contra la aplicación, por lo que estaremos atentos a una actualización que solvente el problema. A día de hoy, no existe parche por lo que hemos podido probar. 

OSX 10.9.2 y Apple Safari 7.0.2: Fallos con la memoria

A mediados de este mes de Marzo, en la lista BugTraq, se publicó un artículo que apunta a una vulnerabilidad de denegación de servicio remota en OS X 10.9.2, Apple Safari 7.0.2, Mozilla Firefox 27 y el antivirus Kaspersky. El bug se encuentra en los controles de memoria en las la función regcomp() de BSD, en GNU/libc() y en los sistemas operativos Apple en regcomp/libc(). Esto quiere decir que una función que llame recursivamente a expresiones regulares puede generar problemas en la memoria llevando a un consumo excesivo y al bloqueo de la aplicación vulnerable.

Para probarlo se pusieron disponibles varias PoC para OS X 10.9.2 y Apple Safari 7.0.2, que nosotros hemos querido testear. El código que se propone en el caso de Apple OS X Mavericks 10.9.2 es una expresión regular lanzada desde la consola de comandos. Como se puede ver, se produce un error en la función de gestión de memoria no controlada, lo que muestra que este defecto está presente en la librería.

Figura 1: Este comando genera un error en la reserva de memoria.

Para el código HTML/JavaScript que se propone en Apple Safari, sí que hemos podido ver que la web se queda pesada y tarda mucho tiempo en responder, pero en ningún momento hemos visto que hubiera que cerrar el navegador - si la pestaña -.

Figura 2: Código HTML/JavaScript para la PoC

En cuanto al consumo de memoria, se puede ver en el comando top que no es excesivo en el sistema, aunque según informan en plataformas Microsoft Windows se han llegado a consumos de 4 GB.

Figura 3: Consumo de la PoC en Apple Safari 7.0.2 sobre OS X Mavericks 10.9.2

En cualquier caso, este problema no está solucionado aún, y deberemos esperar a la nueva versión de OS X Mavericks con una actualización de Apple Safari a ver si lo solucionan.

D.O.S. en Apple Motion con un bug de Integer Overflow

En la lista Full Disclosure se ha publicado hoy mismo un bug sin solucionar para la versión actual de Apple Motion 5.0.7 sobre sistemas operativos Mac OS X Mountain Lion. Dicho bug es un buffer overflow en la configuración del atributo subview en los ficheros .motn y puede ser fácilmente comprobado mediante la creación de un fichero especificado en el reporte de la vulnerabilidad.

Figura 1: Apple Motion 5.0.7 para Mac OS X Mountain Lion

Para ello basta con crear un documento con extensión .motn que tenga el siguiente contenido e intentar abrirlo con la última versión de Apple Motion, que puede ser obtenidas desde la web del producto.

Figura 2: POC de Integer Overflow en Apple Motion 5.0.7

Este bug no está solucionado y parece que no permite la ejecución de código, pero si recibes un fichero que crashea tu aplicación pudiera ser que estuviera explotando este fallo ya conocido de la aplicación. 

OSX 10.8.3 DoS por ftpd Remote Resource Exhaustion

El investigador Maksymilian Arciemowicz ha enviado a la lista de correo de Bugtraq un reporte de seguridad con una demostración en vídeo de un viejo fallo de seguridad en el servicio FTP de equipos con sistema operativo OS X Mountain Lion que, a pesar de haber sido supuestamente corregido por Apple, sigue siendo explotable en OS X 10.8.3 para realizar un ataque de Denegación de Servicio, tal y como se puede ver en el siguiente vídeo.

Figura 1: Vídeo de la PoC de DoS en OS X 10.8.3 con ftpd

El fallo se produce porque por una falta de control en el consumo de recursos que se produce desde una máquina remota en el servicio FTP que utiliza Apple, basado en tnftpd. Incialmente, Apple utilizaba la librería libc que fue parcheada en el CVE-2010-2632 en Mac OS X 10.6.8. Sin embargo, parte del código de libc - incluyendo la función glob vulnerable al CVE-2011-0418 - fue migrada a código propio de Apple, y parece que a partir de la version del 22 de Marzo de 2013 - incluida en OSX Mountain Lion 10.8.3 - el parche de control de recursos no se migró.

Figura 2: CVE-2010-2632 resuelto en Mac OS X 10.6.8

Es decir, Apple ha reintroducido un viejo bug de seguridad en OS X Mountain Lion, lo que lleva a que una prueba de concepto del año 2010 vuelva a funcionar perfectamente para hacer un D.O.S. a cualquier servidor OS X Mountain Lion con el servicio ftp, ya que el consumo de recursos afecta al sistema completo.

Figura 3: Servidores OS X con servicio FTP en Internet descubiertos con Shodan

Como se puede ver en la imagen superior, buscando con Shodan es posible encontrar en Internet miles de servidores OS X con el servicio FTP abierto a Internet que podrían ser objetivos de este tipo de ataques. Si tienes un servidor con Mac OS X Snow Leopard, asegúrate de tener instalada la versión 10.6.8. Si tienes un servidor con OS X Mountain Lion 10.8.3 configura reglas en el firewall de tu red para detectar múltiples conexiones al servicio ftp desde una misma dirección.