Xsser mRAT sigue siendo una amenaza en Android e iOS

Hace unos meses comentamos en Seguridad Apple la existencia de un malware que afectaba a dispositivos iOS denominado Xsser mRAT. Los investigadores que este troyano móvil sigue siendo una amenaza para los usuarios de dispositivos móviles, tanto de Android como de iOS. La empresa que descubrió el troyano fue Lacoon Mobile Security en Septiembre y ha informado de que existe una nueva campaña en países de Asia durante los meses de Octubre y Noviembre. David Fernández, jefe del equipo de PLXsert de Akamai, dijo que los ataques no han sido generalizados, pero esta RAT móvil está adaptada para ataques dirigidos a dispositivos.

Según el informe que ha preparado la gente de Akamai, podemos saber que el factor de infección es el Jailbreak. Lo que es asombroso, y se refleja en el informe es que solamente en China el 14% de los 60 millones de dispositivos iOS tiene Jailbreak.

Acceso remoto: Xsser mRAT

En el informe se especifica como se descubrió el troyano y como se descubrió una variante destinada a infectar dispositivos iOS surgió en el mercado, a través del Jailbreak. La aplicación se instala a través de un repositorio de Cydia y una vez el paquete se ha instalado y ejecutada se confirma la persistencia del malware. A continuación, se realiza comprobaciones del lado del servidor y se procede a la exportación de datos del dispositivo y ejecuta comandos remotos.

El paquete que se descarga con el malware es un archivo con extensión DEB, típica de los paquetes Debian. Consta de varios scripts de instalación un fichero Mach-O, nombre asociado a los binarios de Apple, ejecutable. Tras el proceso de extracción, el archivo postinst ejecuta una serie de comandos de bash para ajustar los permisos de los archivos.

Figura 1: Contenido del fichero bash

Después se ejecuta un script denominado xsser.0day_t.sh, el cual es utilizado para instalar LaunchDaemon plist, otorgando persistencia al troyano. En la imagen se puede visualizar el segundo script lanzado por el malware.

Figura 2: Obtención de persistencia por Xsser

Hosting de la aplicación maliciosa

Para distribuir Xsser mRAT debe ser subido en un repositorio de Cydia o ser almacenado en un host en Internet al que las posibles víctimas pudieran acceder para descargarlo. Según la gente de Akamai los métodos de infección son diversos en este caso, utilizando el SMS, el envío de emails, el uso de Cydia para su distribución, etcétera. Los usuarios deben agregar las fuentes a mano, o ser engañados para agregarlos. Es conocido que muchos usuarios añaden las fuentes sin ninguna garantía de que dicha fuente está a salvo de aplicaciones maliciosas.

Figura 3: myrepospace

Por ejemplo, myrepospace es un sitio web que ofrece alojamiento gratuito para fuentes de Cydia. Esto permite que usuario malicioso pueda subirlo y que las víctimas descarguen aplicaciones de dicho repositorio. Un ejemplo claro es el caso de flappybird a través de Cydia u otros juegos populares que se venden en la AppStore. Se puede utilizar técnicas de phishing para conseguir que los usuarios inserten el repositorio. Esta es una de las vías para que Xsser sea distribuido, pero como comentamos anteriormente hay otras que se utilizan, como el envío de SMS, email, etcétera.

Al final del informe se proprociona una serie de recomendaciones para prevenir la infección del dispositivo iOS. Entre ellas destacan el evitar utilizar conexiones inalámbricas no seguras, utilizar conexiones públicas, utilizar VPN en caso de estar en un entorno no seguro para realizar cualquier operación, ignorar conexiones dónde haya contenido de dudosa procedencia, incluso se habla de la posibilidad de ser víctima de ataques GSM, y de la dificultad de detectarlos por parte del usuario.

Apple liberará iOS 8.0.2 y retira iOS 8.0.1 con urgencia

Fallos en Touch ID con iOS 8.0.1

Después de haber liberado la actualización de iOS 8.0.1, ayer miércoles, los iPhone 6 y 6 Plus se han visto afectados en fallos en la telefenía, el Touch ID e irregularidades generales en el teléfono. Apple quiere hacer algo, que nunca antes ha realizado que sepamos, y es desinstalar iOS 8.0.1, o hacer un downgrade, de nuevo a la versión iOS 8.0, mientras se busca una solución al problema, ya que ha convertido muchos terminales iPhone en meros iPod, al dejarlos sin poder hacer llamadas.

Además del procedimiento de downgrade, Apple identificó los errores que causa la nueva versión para desactivar las funciones de conectividad del teléfono y el Touch ID para muchos iPhone 6 & iPhone 6 Plus propietarios.

Figura 1: Artículo en la knowledge base sobre los problemas con iOS 8.0.1

La compañía está planeando lanzar una nueva versión de iOS 8.0.2 con un parche en los próximos días, según parece indicar un documento de soporte de publicación en la red de la compañía. 

Desde Apple se comunica lo siguiente:

Tenemos una solución para los usuarios si tiene un iPhone 6 o iPhone 6 Plus, los cuales han perdido funcionalidad telefónica y Touch ID después de actualizar a iOS 8.0.1. Puede volver a instalar iOS 8.0 a través de iTunes siguiendo las instrucciones especificadas en el documento. También comunicar que estamos preparando iOS 8.0.2 con una solución para el problema, y se liberará tan pronto como esté listo en los próximos días.

Apple describe un proceso paso a paso para revertir de los iPhone que tienen problemas y volver a la versión anterior de iOS:

1. Asegúrate de que utilizar la última versión de iTunes. 
2. Conecta tu iPhone a iTunes.
3. Realiza una copia de seguridad del iPhone en iTunes. La copias de seguridad a través de iCloud no van a restaurar a las versiones anteriores. 
4. Descarga el archivo correspondiente con tu dispositivo: iPhone 6 o iPhone 6 Plus. Cuidado con este punto ya que seguramente haya ciberdelincuentes intentando aprovecharse de esta descarga para realizar algún tipo de phishing.
5. Selecciona el archivo que se acaba de descargar y a través de iTunes. Después desde Windows o Mac busca las actualizaciones y presione Update para instalar iOS 8 en tu iPhone.

Después de hacer el downgrade, un usuario afectado por los problemas debería ser capaz de realizar llamadas y operar con el Touch ID.  Algo que ya algunos usuarios se preguntan es si alguien podrá aprovechar el mecanismo que Apple implementa para hacer un downgrade para utilizarlo en su propio beneficio.

Hacking & Pentesting dispositivos iOS: iPhone & iPad

En la editorial técnica 0xWord se ha publicado un libro que no debes perderte si te dedicas a hacer pentesting en empresas. Se titula Hacking dispositivos iOS: iPhone & iPad, y recoge en un texto de 320 páginas todas las maneras de atacar un terminal de Apple con iOS.

Figura 1: Portada de Hacking dispositivos iOS: iPhone & iPad

En el libro han participado especialistas en seguridad y pentesting de la talla de Alejandro Ramos "dab", Igor Luckic de EnigmaSec, José Picó y David Pérez de la empresa Taddong y autores del libro Hacking comunicaciones móviles GSM/GPRS/UMTS, Chema Alonso, Pablo González - autor del libro Metasploit para Pentesters -, Juan Garrido "Silverhack", J.M. Aguayo - autor del libro Desarrolllo apps para iOS -, David Barroso, José Selvi de Pentester.es o Ioseba Palop.

Figura 2: Índice del libro de dispositivos Hacking iOS: iPhone & iPad

Se compone de 11 capítulos que abarcan las fases fundamentales de un pentesting, y que te ayudan con demos prácticas en todos ellos. El índice detallado se puede consultar en la opción de Descargas, y está compuesto por los siguientes capítulos:

Capítulo 1: Identificando dispositivos iOS

En este apartado se analizan las diferentes formas de hacer fingerprinting en un proceso de pentesting para descubrir los objetivos. Desde utilizar los USER-Agent de las conexiones, hasta consultar las bases de datos mDNS utilizadas por el protocolo Bonjour, pasando por cómo reconocer un terminal iOS con un scanning nmap.

Capítulo 2: Ataques locales 

En este capítulo se analiza en detalle desde cómo reconocer los terminales con acceso físico, hasta cómo robar cuentas con asociadas a números de teléfono usando las previsualizaciones. Explica en detalle los bugs que permiten saltarse el passcode de un terminal, o cómo usar Voice Control o Siri para sacar información del dispositivo.

Capítulo 3: Jailbreak

En este apartado se explica cómo qué es y cómo puede utilizarse el jailbreak en beneficio de un pentester. Qué herramientas se pueden utilizar, cuáles son útiles para averiguar el passcode de un terminal y cuáles requieren del uso de passcode. Además se explican esquemas de ataque utilizando custom bundles para instalar OpenSHH y tener acceso a los terminales.

Capítulo 4: Atacando el backup

Los terminales iOS hacen backup en sistemas operativos Microsoft Windows, Mac OS X o en Apple iCloud. En este capítulo se explica en detalle cómo está formado un backup de iOS, cómo se puede descifrar, cómo extraer datos manualmente o con Metasploit y cómo sacar la información más jugosa e importante de él.

Capítulo 5: iPhone DataProtection

Esta suite de herramientas es fundamental para cualquiera auditor de seguridad, ya sea analista forense o pentester. En este apartado se ve cómo montar la suite, las principales herramientas y cómo sacar provecho de la misma para sacar claves del terminal.

Capítulo 6: Análisis Forense con Oxygen Forensic Suite

Si tienes un backup o un terminal iOS y quieres sacar todo el jugo del mismo, debes irte a herramientas profesionales que te permitan analizar Gigabytes de datos en apps de manera eficiente. Oxygen Forensic Suite es la que hemos elegido para mostrarte cómo se hace con una de ellas y qué puedes obtener de un proceso de análisis forense profesional.

Capítulo 7: Malware en iOS

En este capítulo aprenderás cómo troyanizar un terminal iOS con Jailbreak, y sin Jailbreak, ya que existen diferentes formas de conseguir instalar un backdoor en un terminal iPhone o iPad que te permita tomar control de muchas de las acciones que se realizan con él. Se analizan troyanos comerciales y cómo construir un troyano en iOS desde cero.

Capítulo 8: JailOwnMe

Este capítulo enseña a hacer re-ingeniería de un exploit de JailbreakMe para convertirlo en una solución de pentester. El trabajo enseña a pensar como un reverser en iOS y a meterse en el mundo de la creación de exploits para esta plataforma.

Capítulo 9: Ataques de ingeniería social y client-side en iOS

Los terminales iOS son herramientas utilizadas como cliente habitual de servicios como Twitter, Facebook, Google+, el e-mail o la Web. En este capítulo se explican los bugs de Address Bar Spoofing, los ataques de phishing y cómo se pueden utilizar herramientas como SET (Social Explotation Toolkit) para atacar usuarios con estos dispositivos.

Capítulo 10: Ataques en redes WiFi

Los terminales iOS se conectan de forma muy particular a redes WiFi, siendo especialmente propensos a Rogue AP, sniffing, y técnicas de man in the middle. En esta sección del libro se explican cómo realizar los diferentes ataques e incluso como atacar sistemas VPN.

Capítulo 11: JavaScript Botnets

Atacando las conexiones WiFi es posible también infectar terminales iOS con una JavaScript Botnet que controle todas las conexiones del terminal. En este capítulo se explica cómo montar una JavaScript Botnet y cómo controlar los terminales iOS.

Capítulo 12: Ataques GSM-GPRS a iOS

Para terminar, los expertos de Taddong explican las peculiaridades de iPhone & iPad en conexiones GSM-GPRS y cómo atacarlos con estaciones base falsas que permitan a un pentester acceder a información de voz y datos de los terminales iOS.

Si te interesa la seguridad de los terminales iOS, Hacking dispositivos iOS: iPhone & iPad es el libro que debes tener para aprender lo fundamental de ellos. Más de 300 páginas de explicaciones y demostraciones que te cambiarán la manera de ver la seguridad de estas tecnologías.

Hacking, forense y desarrollo de apps para Android & iOS

Aprovechando que ayer hablamos sobre Kris/Chris Paget, hoy os vamos a dejar la charla que impartió en la Defcon 18: Practical Cellphone Spying, donde habla sobre cómo atacar las comunicaciones en los dispositivos móviles. Una charla que merece la pena ver para entender mejor la seguridad de las comunicaciones en dispositivos móviles, algo que puedes estudiar en detenimiento en el libro de Hacking de Comunicaciones Móviles.

Además, del 17 al 20 de Diciembre tienes una Formación online sobre Análisis Forense de Dispositivos Móviles que te enseñará los principios en los que se basa el peritaje de dispositivos iPhone/iPad o Android y se mostrarán herramientas profesionales como Oxygen Forensics. Dicha formación se puede seguir a través de Internet, y se realizará durante 10 horas en horario de tarde en España y de mañana en Latino América.

Esta misma semana, del 17 al 20 de Diciembre, en las oficinas de Informática 64 - en Móstoles - tendrá lugar un Curso de Desarrollo de Aplicaciones Android que durará 20 horas y se impartirá en horario de 09:00 a 14:00 horas que es ideal para todos aquellos que quieren aprender los principios de esta disciplina.

Y si lo que quieres es aprender a desarrollar aplicaciones iOS para la App Store siempre puedes comprar el libro de Desarrollo de Aplicaciones iOS para iPhone/iPad que utilizando este código de descuento en las observaciones [DES_iOS_20] lo podréis comprar hasta el día 31 de Diciembre al precio de 20 €.

Busca las diferencias en las direcciones inalámbricas - WiFi y BlueTooth - de tus dispositivos Apple (2 de 2)

Durante los últimos tres años, en numerosas conferencias y eventos de seguridad, he promulgado lo importante que es que los fabricantes conozcan las implicaciones de seguridad que tiene la integración de diferentes tecnologías en un mismo dispositivo. En concreto, la integración de Bluetooth y Wi-Fi en un mismo dispositivo móvil puede verse afectada por un desconocimiento de los principios de seguridad de cada una de estas tecnologías inalámbricas. La situación no ha cambiado mucho en todo este tiempo… y tras plantearos que hicierais vosotros las pruebas en la primera parte de este artículo, toca analizar la situación en Apple.

Implicaciones de seguridad en las direcciones Bluetooth y Wi-Fi

La tecnología Bluetooth emplea las direcciones hardware de los dispositivos, o BD_ADDR (Bluetooth Device ADDRess), como algo secreto, es decir, un elemento que una vez conocido abre la puerta para que otros dispositivos puedan establecer conexiones. Los dispositivos Bluetooth pueden configurarse en dos modos, visible u oculto, y la diferencia principal entre ambos es sí el dispositivo revela cuál es su dirección BD_ADDR cuando otros dispositivos preguntan quién anda cerca (operación conocida como Bluetooth inquiry).

Adicionalmente, la BD_ADDR del maestro (junto a otros elementos, como información del reloj) son empleados para derivar el patrón de saltos de frecuencia (utilizado en FHSS, Frecuency Hopping Spread Spectrum) que se empleará para la comunicación. Si se conocen esos valores también es posible utilizar un sniffer Bluetooth para capturar la comunicación.

Debido a que la BD_ADDR debe ser protegida, ésta no es enviada en las cabeceras de las tramas Bluetooth (802.15), sino que en su lugar se envía un digito (0-7) que identifica a los dispositivos. Este dígito de 3 bits se denomina Active Member Address (AMA) y lo obtienen los dispositivos al unirse a la red Bluetooth (o piconet).

Sin embargo, la tecnología Wi-Fi, al igual que la mayoría de los protocolos de comunicaciones, no emplea ningún mecanismo de protección, o confidencialidad, sobre las direcciones hardware de los equipos. Es posible obtenerlas mediante una sencilla y rápida captura de tráfico, ya que las direcciones de los equipos - origen y destino, y del punto de acceso, o repetidores, en WDS -, se incluyen sin cifrar en las cabeceras de todas las tramas Wi-Fi (802.11), independientemente de los mecanismos de seguridad y cifrado empleados (WEP, WPA, WPA2, etc).

Por tanto, en el caso de existir alguna relación entre las direcciones Bluetooth y Wi-Fi de un dispositivo móvil, es trivial para un atacante capturar el tráfico Wi-Fi de la víctima y derivar inmediatamente la dirección Bluetooth. A partir de la dirección Bluetooth, el atacante podrá comunicarse con el dispositivo e intentar identificar la ausencia de mecanismos de seguridad en Bluetooth - autentificación o autorización - o explotar vulnerabilidades a través de ese interfaz.

Peculiaridad en la asignación de direcciones para interfaces inalámbricos en Apple

En este caso, como indicábamos en la primera parte de este artículo, le ha tocado el turno a Apple - sin excluir a otros fabricantes -, ya que desde las primeras versiones de iPhone (ej. 2G) Apple utiliza un mecanismo desde fábrica de asignación de direcciones hardware secuencial para los interfaces inalámbricos de sus dispositivos y, desafortunadamente, esta inapropiada práctica no ha cambiado con los últimos modelos (ej. iPhone 4 o iPad 2). Las direcciones Bluetooth y Wi-Fi de los dispositivos Apple son asignadas secuencialmente, por lo que sólo cambia el último byte:

Dispositivo: iPhone 3G

BD_ADDR: 00:21:E9:AB:CD:01

Wi-Fi MAC: 00:21:E9:AB:CD:02

Tras realizar un estudio más exhaustivo sobre un conjunto de algo mas de una docena de dispositivos Apple, hemos llegado a las siguientes conclusiones:

• Los equipos Apple de “sobremesa” (MacBook, MacBook Pro, iMac…) no utilizan la asignación secuencial de direcciones, no siendo posible derivar la dirección Bluetooth a partir de la dirección Wi-Fi, pese a que ambas pertenecen a rangos asignados a Apple por el IEEE. En estos equipos puede coincidir el cuarto byte de la dirección Bluetooth y Wi-Fi. Algunos rangos empleados coinciden con los de los iPad, por ejemplo, C8:BC:C8.

• Los dispositivos móviles de Apple utilizan direcciones secuenciales, presentándose dos escenarios distintos, y una excepción encontrada:

 - La dirección Bluetooth es la anterior a la dirección Wi-Fi, caso común en iPhone 2G, 3G, 4 o iPad2.

 - La dirección Bluetooth es la posterior a la Wi-Fi, caso común en iPad o MacBook Air.

 - Excepción: Hemos identificado, al menos, un iPad donde la dirección Bluetooth es la anterior a la dirección Wi-Fi.

• Habitualmente, Apple emplea rangos de direcciones según el tipo del dispositivo (con excepciones, como la de los equipos de sobremesa y los iPads; ver primer punto).

Esta última conclusión tiene especial relevancia desde el punto de vista de seguridad, ya que mediante una sencilla captura del tráfico Wi-Fi sería posible identificar el tipo de dispositivo de Apple si dispusieramos de una base de datos que clasificara los dispositivos Apple en función de la parte del fabricante de su dirección hardware (primeros tres bytes). ¿Sería interesante disponer de esta base de datos? (Envíame un mail a raul en taddong.com).

Por otro lado, si me tocara realizar la asignación de direcciones, aunque por seguridad emplearía aleatoriedad, usaría un patrón secuencial consecutivo, es decir, empezaría (por ejemplo para iPhone) por la dirección :00 para Bluetooth y :01 para Wi-Fi, y así sucesivamente, hasta llegar a :0E y :0F. Podemos confirmar que Apple no sigue ese esquema, ya que hemos visto dispositivos dónde la direcciones Bluetooth y Wi-Fi son la :_9 y :_A respectivamente, y otros donde son la :_A y :_B, por lo que parece que no empiezan siempre desde cero consumiendo direcciones de dos en dos hasta completar las 16 direcciones posibles de cada carácter hexadecimal de la dirección.

Conclusiones

En resumen, Apple asigna las direcciones empleando un criterio que no parece ser muy homogéneo, salvo en su secuencialidad, haciendo vulnerable a los dispositivos móviles y facilitando conocer la dirección Bluetooth a partir de la dirección Wi-Fi.

Si encuentras algún dispositivo dónde las reglas mencionadas previamente (dirección anterior o posterior según el tipo de dispositivo) no se cumplen, no dudes en añadirlo a los comentarlos de esta entrada de blog, con el objetivo de identificar con más exactitud el patrón empleado por Apple y disponer de más ejemplos.

Una última recomendación de seguridad… si no estás usando Bluetooth o Wi-Fi en tu dispositivo en un momento determinado, deshabilita estos interfaces y habilitalos únicamente cuando hagas uso de ellos. ¡Tú bateria y el planeta también te lo agradecerán! ;-)

Raúl Siles

Investigador de Seguridad en Taddong Security

Los días 1, 2 y 3 de Junio Taddong dará un Curso de Seguridad GSM/UMTS (2G/3G) en Valencia

iPhone no alerta de conexiones GSM sin cifrar

Ya hemos hablado en otras ocasiones sobre el trabajo de los investigadores de Taddong sobre la seguridad en las comunicaciones GSM/GPRS/Edge/3G. Con parte del trabajo que habían estado realizando dieron una conferencia de seguridad en la prestigiosa Black Hat DC 2011 en la que mostraban como se podrían realizar ataques a dispositivos que no tienen protección contra la suplantación de redes.

Suplantación de redes GPRS

La idea que se esconde detrás de las demostraciones que realizaron es que los dispositivos que utilizan redes GPRS no autentican al operador, mientras que, cuando se utiliza una red 3G, sí existe dicha comprobación, evitando así la posible suplantación de un operador. Por desgracia, dispositivos como iPhone o iPad no permiten forzar el uso de redes únicamente 3G con lo cuál pueden ser vulnerables a este tipo de ataques.

Redes GSM sin cifrado

En esta ocasión, los investigadores han escrito un interesante artículo en el que han analizado el comportamiento de los terminales y los operadores ante el uso de GSM sin ningún cifrado. La tecnología GSM permite utilizar los protocolos A5/1, que es el cifrado estándar GSM y que, desde hace ya algún tiempo está roto, y el protocolo A5/0 que significa que no se está utilizando ningún sistema de cifrado.

La especificación GSM dice que el indicador de uso de una red sin cifrado, es decir, con el protocolo A5/0 debe ser sabido por el usuario, por lo que debe mostrarse un indicador de conexión no cifrada. En algunos países, como por ejemplo India, es obligatorio el uso de sistemas no cifrados, pero en otros países en los que hay una ley concreta para garantizar la privacidad de las comunicaciones, se utilizan sistemas de cifrado en todas las redes.

Deshabilitado del indicador de red GSM sin cifrado

No obstante, el indicador de red no cifrada puede ser deshabilitado por la red del operador modificando la un parámetro en la tarjeta SIM del operador. Sin embargo, si el operador no ha deshabilitado esta función el estándar GSM deja muy claro que el icono alertando al usuario debe ser mostrado.

"The ciphering indicator feature allows the ME to detect that ciphering is not switched on and to indicate this to the user. The ciphering indicator feature may be disabled by the home network operator setting data in the SIM/USIM. If this feature is not disabled by the SIM, then whenever a connection is in place, which is, or becomes unenciphered, an indication shall be given to the user. Ciphering itself is unaffected by this feature, and the user can choose how to proceed."

El test final con Nokia 6230 e iPhone 3G

Para probar como se comportaban ante esta situación, los investigadores de Taddong Security decidieron conectar dos teléfonos con dos tarjetas de dos operadores, a los que llaman Operador1 y Operador2 para no dar los nombres, con un teléfono Nokia 6230 del año 2004 y un iPhone 3G del año 2008 a una red GSM falsa que estaba utilizando A5/0. El resultado es el que se puede ver en la Figura1.

Como se puede observar, el teléfono Nokia 6230 avisa de que la red no tiene ningún sistema de cifrado en la comunicación GSM, mientras que iPhone no muestra ninguna advertencia de esta situación. No obstante, en este caso podría ser, como así sucede, que la tarjeta SIM que tiene instalada el teléfono iPhone tenga deshabilitado el indicador de red no cifrada.

Figura 1: El candado abierto arriba a la izquierda indica red sin cifrar

Para comprobar cuál es el comportamiento real del iPhone 3G procedieron a cambiar las tarjetas e insertar la  SIM que tenía el teléfono Nokia 6230, y que como se ha comprobado no tiene deshabilitado el indicador, para ver como se comportan.

Figura 2: Ningún mensaje de alerta de red sin cifrado

En este caso el dispositivo iPhone sigue sin mostrar el indicador de alerta, con lo que es evidente que iPhone no está haciendo caso del estándar GSM para esta situación, mientras que el teléfono Nokia 6230 tampoco lo muestra porque la operadora lo ha deshabilitado.

Los investigadores de Taddong impartirán cursos de seguridad GSM/UMTS en Madrid, Valencia y Barcelona, en español e inglés a los que puedes apuntarte.