idb: Herramienta para reversing de aplicaciones iOS

Hoy hablaremos de idb una herramienta para los sistemas macOS que puede simplificar algunas tareas comunes para llevar a cabo evaluaciones de seguridad de aplicaciones iOS, en el ámbito del reversing, y de la pura investigación. En el sitio web de la herramienta se puede encontrar documentación y prácticas basadas en el análisis de iGoat o de la aplicación Damn Vulnerable iOS o DVIA, que son recursos utilizados para familiarizarse con las vulnerabilidades de las aplicaciones iOS.

La herramienta proporciona al usuario una gran cantidad de features, desde el análisis de código como el análisis del binario, como son las que se enumeran a continuación: 

• Información de la aplicación. Información de dónde se almacenan los datos, versiones de SDK, información de las dependencias, etcétera.
• Almacenamiento de datos y cómo estos se almacenan. Listado de clases y de permisos plist, sqlite y cache.db. Dump del fichero Keychain. 
• Análisis de binarios. Se chequea el cifrado de la app, las protecciones como DEP, ASLR o ARC. Extracción de strings del binario y dump de clases y métodos. 
• Otras pruebas. Se analizan otras partes de la aplicación como los certificados instalados o la utilización de fuzzers para provocar fallos en la aplicación, a través de los datos de entrada. 

Figura 1: idb para macOS

En líneas generales, interesante herramienta que puede ser obtenida desde su sitio web y que está disponible para los usuarios de macOS. Estas navidades, aprovecha y comienza con el análisis de aplicaciones iOS con este tipo de herramientas. Por otro lado, no olvides también la herramienta iRET, la cual permite realizar ingeniería inversa sobre aplicaciones iOS.

Cómo ver la hora de cada iMessage en iPhone & iPad

Una de las peculiaridades que tiene el sistema de visualización de conversaciones iMessage en iOS, es que agrupa los mensajes que han sido parte de una misma conversación mostrando solo una fecha aproximada de cuándo fueron enviados o recibidos. Esto es algo que a mucha gente molesta porque quieren saber el instante exacto de cada mensaje en algunas ocasiones, y nosotros llegamos a meternos en las entrañas de la base de datos para sacar del SQLite toda la información de los menajes, tal y como os mostramos en el artículo de "Almacenamiento de mensajes SMS e iMessage en iOS".

Hoy queremos contaros un pequeño tip que no sabemos desde cuando está en iMessage, pero que te puede ahorrar la tarea de ir a destripar la base de datos para saber la hora de envío o recepción de un iMessage, y es que ahora - no sabemos exactamente desde qué versión - se pueden ver las horas de los mensajes arrastrando la pantalla hacia la izquierda.

Figura 1: Si se arrastra la pantalla a la izquierda salen las horas de los iMessages

Tal vez lleva tiempo esta función, pero nosotros no la teníamos ubicada, y puede que como nosotros muchos de vosotros tampoco, así que os la hemos querido contar, que como la opción de forzar el envío por SMS de iMessages, nos la topamos sin querer. Eso sí, en el cliente iMessage de OSX 10.9. 4 Mavericks, todavía no hemos conseguido sacar ese dato, por lo que seguimos tirando de técnicas de análisis forense.

Figura 2: Conversación sincronizada de iMessage en OS X 10.9.4 Mavericks

A esto, hay que ver que la sincronización temporal de los mensajes es un poco desastre y una misma conversación, que se originó desde el cliente iOS aparece sinconizada en el cliente OS X con dos minutos de anticipación. Eso es viajar en el tiempo y lo demás tontería. Si conoces algún truco para no tener que ir a destripar el almacenamiento de conversaciones en los ficheros te lo agradeceremos. 

Almacenamiento de mensajes SMS e iMessage en iOS

En el post de hoy vamos a ver en profundidad cómo funciona, en términos de almacenamiento, el sistema de mensajería de Apple. Todas las versiones de iOS hacen uso de SQLite, un sistema de gestión de bases de datos que implementa la práctica totalidad del estándar SQL, para almacenar los mensajes SMS y los chats de iMessage. Podemos encontrar la base de datos en la ruta /var/mobile/Library/SMS/sms.db, pero para poder acceder a ella es necesario haber hecho jailbreak al terminal. Una vez accedemos, vemos que está estructurada en nueve tablas.

Figura 1: Estructura de la base de datos.

A continuación se explica la funcionalidad de cada tabla.

• _SqliteDatabaseProperties: almacena información relativa a la base de datos.
• attachment: almacena los archivos adjuntos de los mensajes.
• chat: almacena las diferentes conversaciones de iMessage y SMS.
• handle: almacena datos de los usuarios, como id, país y servicio que utilizan (iMessage o SMS)
• message: almacena los mensajes de las conversaciones.
• chat_handle_join: relaciona las tablas chat y handle.
• chat_message_join: relaciona las tablas chat y message.
• message_attachment_join: relaciona un mensaje y sus adjuntos.
• sqlite_sequence: contiene una entrada por cada tabla con clave primaria autoincrementable.

Como podemos ver, las tablas "join" establecen relaciones (vía identificadores) entre las tablas que contienen los datos.

Figura 2: Texto de los mensajes en la tabla Message

En la figura superior vemos el contenido de la tabla 'message', donde se almacenan los datos de cada mensaje (contenido, usuario emisor y receptor, fecha, etc...). Abajo podemos ver un ejemplo de lo que contiene la tabla chat. La tabla contiene una entrada por cada conversación mantenida por el usuario, indicando usuarios involucrados, servicio, etc.

Figura 3: Descripción de la tabla chat.

Hay algo que es importante comentar respecto a cómo almacena los mensajes Apple. La fecha de los campos date y date_read de la tabla message no parece, a priori, legible. Esto se debe al formato que utiliza Apple para almacenar fechas. Apple utiliza su propia versión modificada de Unix Epoch, el formato de fecha que utilizan los sistemas Unix y muchos lenguajes de programación. Este formato toma como fecha de referencia el 1 de Enero de 1970 a las 00.00, contando el número de segundos transcurridos desde ese instante.

Apple, por su parte, considera como momento cero el 1 de enero de 2001, ya que en 2001 fue el año de lanzamiento del Mac OS X 10.0. Debido a esto, para manejar fechas en SQLite debemos tener en cuenta cierto offset, concretamente la diferencia entre el punto de referencia de Apple y el de Unix Epoch. Este valor se puede calcular con la siguiente consulta:

SELECT strftime('%s', '2001-01-01 00:00:00');

Que básicamente devuelve los segundos transcurridos entre la medianoche del 1 de enero de 1970 y el 1 de Enero de 2001, es decir, 978307200. Así pues, para obtener una fecha en formato Unix Epoch a partir de la fecha de Apple, basta con sumar el offset al realizar la consulta. Siendo date la fecha que queremos convertir.

SELECT datetime(date+ 978307200,'unixepoch','localtime') FROM message

Las características estructurales de la base de datos SQLite, especialmente en lo que a relación entre tablas se refiere, así como la particular manera en la que Apple almacena las fechas hacen que sea necesario familiarizarse con ella si se quiere abordar desde un punto de vista de seguridad. Además, a nivel de usuario, nunca está de más conocer cómo funciona internamente una aplicación que maneja datos tan sensibles como los nuestros mensajes personales.

Estudio revela graves fallos en las apps de banca para iOS

Casi todos los bancos hoy en día, por no decir todos, cuentan con apps para el sistema operativo iOS que permita a sus clientes gestionar sus cuentas desde terminales iPhone o iPad. Con 40 de las apps, pertenencientes todas ellas a bancos del Top 60 mundial, el investigador Ariel Sánchez, de la conocida empresa consultora en seguridad informática IOActive, decidió hacer un estudio mirando la calidad y seguridad de las mismas. Las apps fueron elegidas de bancos distribuidos geográficamente por todo el mundo, tal y como se puede ver en este gráfico.

Figura 1: Distribución de los bancos dueños de las apps auditados en este estudio

En solo 40 horas de trabajo, probando una serie de tests de seguridad orientados a validar la seguridad únicamente del código del cliente, es decir, sin mirar ni probar nada en el lado del servidor. Para las pruebas se utilizaron las herramientas ootol, el popular Burp Pro y conexiones SSH al terminal con jailbreak sobre el que se corrieron las apps. El resultado del número de bugs encontrados está recogido en la siguiente gráfica.

Figura 2: Resumen de vulnerabilidades encontradas en las apps

Según se publica en los resultados, algunos datos arrojan apps peligrosas:

- 40 % de las apps no validan la autenticidad del certificado del servidor: Es decir, que no hacen las validaciones oportunas para comprobar que es el correcto, como podría ser hacer un uso de Certificate Pinning lo que dificultaría la posibilidad de hacer ataques Man in the middle. Esto es algo que en el pasado le ocurrió a la propia app de Paypal para iOS.

- 90 % de las apps contienen links en las UIWebViews que no van bajo SSL: lo que permite interceptación de datos e inyección de comandos JavaScript/HTML en el cliente para hacer ataques que permitan robar datos e incluso enviar mensajes SMS o e-mails desde el terminal.

Figura 3: Códigos JavaScript/HTML inyectados bajo un ataque man in the middle

Entre otros ataques, por supuesto está como se ve en la imagen superior la posibilidad de inyectar un falso formulario de login que haga phishing a través de la UIWebView para robar las credenciales. El formulario de este ejemplo es el siguiente código inyectado.

Figura 4: Código inyectado para hacer el robo de credenciales con un falso login

- El 70 % de las apps no tenían una autenticación de segundo factor disponible: En estos casos hace referencia a que los usuarios se pudieran autenticar con tokens RSA, validación con mensajes enviados por SMS o el uso de alguna tecnología similar a Latch para aprobar si la cuenta está activa o desactivada - puedes probarlo en el banco de pruebas Nevele Bank -.

- Ficheros de log con información sensible: La mayoría de los ficheros de log cuando se produce un crash de la app contenían información sensible filtrada que podrían ayudar a un creador de exploits a preparar un 0day contra esa app en el cliente en un esquema de ataque APT client-side.

Figura 5: Informe de crash con información leakeada

A esto hay unir que menos del 20 % de las apps no tenían activadas las opciones de Position Independent Executable (PIE) y Stack Smashing Protection que ayudarían a dificultad la creación de exploits consistentes.

- Uso incorrecto de información de debugging en el ASL: También la mayoría de las apps hacían el uso abusivo de datos al Apple System Log, dando como resultado fugas de información que podrían ser accedidas por otras apps dentro del mismo terminal.

En una segunda parte del estudio se hizo un análisis estático de las apps utilizando las herramientas de ingeniería inversa como gdb, IDA Pro, Clutch o IPCU, pudiendo sacar datos más que jugosos de cómo están construidas algunas apps, como pueden ser los siguientes:

- Credenciales de desarrollo hardcoded en el código: En una app se pudo acceder a un usuario y contraseña utilizado en proceso de desarrollo de la app que se había quedado en la compilación.

Figura 6: Credenciales usadas en el desarrollo de la app almacenadas en el código

- Fuga de información de infraestructura: En muchas apps era posible conocer la estructura del sitio del servidor sólo con analizar el código, donde se puede acceder a URLs internas de la organización escritas en él.

Figura 7: Información de URLs de las apps

- Fugas de informaciones menores: También algunas apps contenían información de los servidores internos utilizados y rutas de ficheros de los equipos de los desarrolladores.

Figura 8: Direcciones IP internas y rutas locales de usuarios desarrolladores

Por último, muchas de las apps hacen uso de almacenamiento inseguro de información, algunas de ellas en bases de datos SQLite sin cifrar que permiten acceder a datos de las cuentas de los clientes de las apps de forma muy sencilla.

Figura 9: Bases de datos SQLite con información sensible sin cifrar

Hay que recordar que el uso de bases de datos SQLite puede llevar a que mucha de la información que de ellas se borra pueda ser recuperado por servicios como Recover Messages que es capaz de localizar las páginas borradas y recomponer los datos para extraer qué registros fueron borrados de cualquier base de datos SQLite.

Obtener base de datos de mensajes WhatsApp en iPhone

Para obtener las conversaciones existentes o borradas del WhatsApp de un iPhone no es necesario hacer jailbreak al dispositivo, aunque si no se conoce el passcode del terminal sería una opción. La forma más sencilla es conectar el terminal iPhone al equipo donde está sincronizado - ya sea un Mac OS X o un Microsoft Windows - y conectarse vía la aplicación i-FunBox u otra herramienta similar.

Una vez conectado, se debe ir a la ruta Aplicaciones de Usuario -> WhatsApp -> Documents y allí seleccionar la opción del menú contextual Copiar al PC/ Mac el fichero ChatStorage.sqlite.

Figura 1: Obtención de la base de datos de WhatsApp de un iPhone sin Jailbreak con iFunBox 

Una vez obtenido, se puede subir a la web RecoverMessages.com donde se obtendrán no sólo las conversaciones y ficheros no borrados tras descifrar la base de datos, sino que con técnicas forenses es posible acceder a los registros de conversaciones eliminados.

Figura 2: Subida de bases de datos de WhatsApp, SpotBros, Tuenti o iPhone a RecoverMessages

Si la base de datos tiene pocos mensajes el servicio es gratuito, pero si es de gran tamaño será necesario obtener una licencia para recuperar lo mensajes borrados de la base de datos de WhatsApp.

Figura 3: Recuperación de registros borrados de WhatsApp

El servicio Recover Messages soporta también bases de datos de Tuenti, SpotBros y Line para iOS, con lo que se puede obtener todo lo chateado por esas aplicaciones desde un terminal iPhone o iPad.

Mac OS X: Analizar historial de descargas usando XProtect

Desde Mac OS X 10.6 Snow Leopard en el sistema operativo está disponible XProtect, una especie de solución "antimalware" que intenta detectar firmas de las familias más utilizadas en Internet, aunque como ya vimos este número es más bien reducido y no es excesivamente bueno. Sin embargo, para los analistas forenses, la información que genera es extremadamente útil, ya que todas las aplicaciones que hacen uso de él, añaden la URL de descarga como metadata extendido al fichero que puede verse com xattr.

Figura 1: URL de descarga del instalador de Firefox

Esto puede ser especialmente útil para rastrear un malware en el sistema, o simplemente para recomponer el historial de navegación de un usuario de Google Chrome, Mozilla Firefox o Apple Safari, sólo con analizar las URLs de las descargas que se han realizado.

Figura 2: URL de dónde se descargó un fichero visto en Finder

Sin embargo, como explica Mr Wolf en Lost in Security, existe una base de datos en SQLite dentro del perfil de usuario, que puede consultarse directamente para extraer la información de todo lo que ha sido descargado. Esta base de datos está situada en:

$HOME/Library/Preferences/com.apple.LaunchServices/LSQuarantineEventsV2

Si entramos en ella, veremos que solo hay una tabla, de la que podemos describir sus campos.

Figura 3: conexión a la base de datos y descripción del contenido

Estos campos, almacenan la siguiente información:

LSQuarantineEventIdentifier: identificador UTI que se usa como clave primaria.

LSQuarantineTimeStamp: fecha de descarga, representada en segundos desde el 1 de enero de 2001 12:00 AM (es decir, que hay que sumar 978307200 segundos para poder tener un UNIX timestamp normal).

LSQuarantineAgentBundleIdentifier: el nombre del bundle del programa que ha descargado el archivo (por ejemplo com.google.Chrome).

LSQuarantineAgentName: el nombre del programa que ha descargado del archivo (por ejemplo Google Chrome).

LSQuarantineDataURLString: la URL desde donde se ha descargado el archivo.

LSQuarantineSenderName: el nombre de la persona que envió un attachment de correo (es decir, sólo se pone si LSQuarantineTypeNumber es igual a '2').

LSQuarantineSenderAddress: la dirección de la persona que envió un attachment de correo, igual que en el caso anterior.

LSQuarantineTypeNumber: el tipo de método de descarga:

0 si es web (kLSQuarantineTypeWebDownload)

1 si son otros programas (kLSQuarantineTypeOtherDownload) - como por ejemplo Transmission, o el mismo XCode

2 si son attachments de correo (kLSQuarantineTypeEmailAttachment)

3 si son attachments de programas de mensajería instantánea

(kLSQuarantineTypeInstantMessageAttachment); iChat

4 si es calendario (kLSQuarantineTypeCalendarEventAttachment)

5 si son otros attachments (kLSQuarantineTypeOtherAttachment)

Figura 4: Consulta de programa utilizado y URL de descarga

Como se puede ver, basta con hacer una consulta Select con los campos que más nos interesen en un análisis forense y poder reconstruir el historial de navegación de un usuario, los ficheros adjuntos descargados en correos electrónicos o qué aplicaciones ha estado utilizando.

Seminarios de desarrollo de aplicaciones iOS

La semana que viene, desde el lunes 2 de Julio hasta el viernes 7 de Julio en Madrid, hay uno cada día de seis horas de duración, en horario de 08:30 a 14:30 horas. Comenzarán con una primera toma de contacto con XCode, Objective-C y los paradigmas de diseño en iOS, continuando con la creación de interfaces gráficas, con el estudio de eventos, persistencia, para finalizar con los conceptos sobre cómo crear aplicaciones cliente-servidor, realizar conexiones a servicios web, servlets, etcétera. 

El profesor de todos estos seminarios será Juan Miguel Aguayo, autor del libro Desarrollo de Aplicaciones iOS para iPhone&iPad: Essentials, así que, si sueñas con tener tu propia app en la AppStore, o tienes buenas ideas y quieres implementarlas en una de las disciplinas de mayor proyección profesional, entonces no dejes pasar esta oportunidad. Tienes la información de cómo registrarse a cada uno de estos eventos en la web de Próximos Eventos de Informática64. A continuación os dejamos un resumen de cada uno de ellos:

Objective-C e iOS

En este primer seminario se aprende todo lo necesario para aquellos que se enfrentan por primera vez al mundo iOS, y desean desarrollar aplicaciones en él. Desde como manejar el entorno de desarrollo de Apple, pasando por la toma de contacto con el lenguaje Objective-C (imprescindible para los profanos en la materia), patrones o paradigmas de diseño en iOS, las diversas plantillas de XCode, y finalizando con el desarrollo de aplicaciones que muestren de manera didáctica como implementar las primeras aplicaciones.

Creación de interfaces gráficas

En este seminario se aprenderá a implementar interfaces gráficas, utilizando los distintos controladores que iOS ofrece. Se estudian los las diversas vistas existentes en el SDK, los diferentes contenedores (de vista, de navegación, TapBar, vista web, etcétera) y cómo combinarlos para crear aplicaciones reales y complejas.

Persistencia de datos

Aquí se verá de manera práctica cómo almacenar datos de manera persistente en ficheros, cómo utilizar el framework de alto nivel para persistir datos (CoreData) y cómo utilizar la librería SQLite a bajo nivel. Por último se presenta cómo utilizar el sistema de preferencias de usuario NSUserDefaults, que permite almacenar pequeños conjuntos de valores, preferencias, configuraciones, etcétera, y que estos sean manejados desde el menú general de configuraciones del dispositivo, es decir, fuera de la aplicación en cuestión.

Gestión de Eventos

En este seminario se presentan los conceptos y teoría relacionada con eventos y los diferentes tipos de eventos que existen en iOS. Se aprende cómo manejarlos, gestionarlos, programarlos, etcétera. Se realizará la implementación de aplicaciones para mostrar de manera didáctica cómo implementar eventos multi-touch, eventos de movimiento y eventos de control remoto.

Aplicaciones Cliente/Servidor 

En este seminario se aprende a implementar aplicaciones cliente-servidor, es decir, cómo utilizar las herramientas que brinda iOS para comunicarse con un servidor. Además se estudia como realizar parseo de ficheros XML y JSON, imprescindible para una comunicación ligera y eficiente con un backend server. Se realizará la implementación de un cliente que consuma feeds XML y aplicaciones que conecten con servicios web.