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.

Zerodium sube hasta 1.5 Millones de dólares por los 0days de iOS, que sigue siendo "oro"

La compañía Zerodium centrada en la compra-venta de exploits ha subido lo que está dispuesto a pagar por un exploit de 0day para iOS que permita la ejecución de código arbitrario remotamente. Este exploit podría permitir tomar el control de un terminal iPhone o iPad y ejecutar en él cualquier programa, lo que puede ser el deseo de los ciberespías de todo el mundo, así como del mundo del cibrecrimen que podría explotar campañas masivas de infección en estos terminales.

Figura 1: "Tabla periódica" de tecnologías elegibles, tipos de exploits y valor de los mismos

En la web de Zerodium se ha publicado la "tabla periódica" de cuál es el valor que dan a cada uno de los exploits dependiendo de las tecnologías que se vena afectadas y, como se ha dicho, la reina sigue siendo sin lugar a duda la ejecución de código arbitrario de forma remota en iOS.

Figura 2: Lista de exploits elegibles parte 1

No todos los exploits son elegibles para optar a una opción de compra, por lo que también hay una lista de los tipos de fallos que son aceptados para cada una de las tecnologías, como puede verse en la imagen siguiente.

Figura 3: Lista de exploits elegibles parte 2

Si eres un investigador de seguridad, tal vez puedas acabar viviendo de forma muy holgada gracias a tus capacidades tecnológicas, así que, no te lo pienses y comienza a focalizar tus esfuerzos en aquella búsqueda que más te interese.

Resetear la contraseña del EFI firmware en MacBook #Macbook #Apple

En el artículo de hoy traemos un brillante post de reversing en el que se enseña a "jugar" con el firmware EFI de Apple. La investigación comenzó con el objetivo de encontrar una forma de restablecer la contraseña del firmware de un MacBook. El investigador se encontró con referencias a un archivo SCBO, el cual puede ser cargado en una unidad flash USB y arrancar con el objetivo de eliminar la contraseña. El archivo SCBO permite verificar el número de serie del dispositivo. 

El archivo SCBO comienza con un magic number: 0x4F424353, el cual se puede leer la cadena SCBO. El soporte de Apple puede generar estos ficheros SCBO pidiendo algún dato importante al usuario que lo solicita. En este post vamos a ver cómo poder hacer esto, pero te recomendamos el libro de MacOS Hacking que habla de muchos temas que pueden serte de ayuda en situaciones similares.

Figura 1: Libro de MacOS Hacking

Para obtener la información necesario para el soporte se debe mantener pulsado SHIFT + CONTROL + Opción + Comando + S en la pantalla de solicitud de contraseña del firmware y se genera una cadena. Esta es la cadena que necesita el soporte de Apple, y esta es la misma cadena que se puede ver dentro del archivo SCBO. Los primeros dígitos son el número serie de la máquina, mientras que los últimos 16 dígitos son un valor que se regenera cada vez que se ha restablecido la contraseña del firmware. 

Figura 2: Obtención del serial

El procedimiento para utilizar un fichero SCBO es el siguiente. El objetivo es conseguir resetear una contraseña del firmware del dispositivo.

1. Formatear una partición flash con Mac OS Extended. Se debe llamar Firmware.
2. Arrastrar el archivo binario llamado SCBO al escritorio.
3. Abrir terminal.
4. Ejecutar el comnado cp ~/Desktop/SCBO /Volumes/Firmware/.SCBO
5. Ejecutar este comando cp ~/Desktop/SCBO /Volumes/Firmware/._SCBO
6. Extraer la unidad flash.
7. Apagar el equipo.
8. Insertar la unidad flash en el ordnador cliente.
9. Encender el ordenador mientras mantiene pulsada la tecla Opción.
10. Se debe visualizar el símbolo de bloqueo y luego el equipo debe reiniciar el gestor de arranque.

Si pierdes la contraseña de tu firmware, tu podrás resetarlo. En el artículo sobre la investigación del reversing y reseteo del firmware EFI de Apple se puede obtener total detalle sobre la operación y la investigación. Interesante y gran trabajo realizado en el área del reversing en sistemas Apple.

Objetive-C Exploitaition Techniques & OSX Kernel Rootkits

En la Phrack Magazine número 69 publicada en este mes de Mayo, se han incluido una serie de interesantes artículos para los hackers. Entre ellos, hay dos que nos gustaría destacaros si estáis aquí porque vuestro interés se centra - sobre todo - en lo que a Apple atañe. El primero de los artículos está centrado en Objetive-C, y bajo el título de "Modern Objective-C Exploitation Techniques" explica algunas de las formas más modernas y avanzadas para explotar bugs en aplicaciones escritas en Objetive-C. Saca tiempo y concentrate, porque el artículo es largo y exhaustivo.

Figura 1: Modern Objetive-C Exploitation Techniques

Y el segundo de ellos, centrado en la creación de Rookits a nivel de Kernel en OS X. En este caso, centrándose en los sistemas operativos más modernos de Apple para repasar los cambios que se han producido en las tablas del sistema, en las funciones en las que hacer el hooking de las llamadas, etcétera. Estos son los contenidos de este segundo artículo.

Figura 2: Tabla de Contenidos de "Revisiting Mac OS X Kernel Rootkits"

Como podéis ver, dos joyas para los amantes del reversing, el exploiting y el malware analysis que disfruten de las tecnologías Apple en su día a día. Imprescindibles sin quieres conocer a fondo tanto Objetive-C como OS X.

Reverseando el bug de syslogd en OS X El Capitan

Hace unos días se libero un conjuntos de actualizaciones para OS X El Capitan, Yosemite y Mavericks. En el boletín se describían vulnerabilidades relacionadas, en su mayoría, con el kernel e IOKit. Uno de los problemas de seguridad que se solventan trata de un problema de corrupción de memoria en syslog, el cual podría provocar la ejecución de código arbitrario, es decir, ejecución de un payload que permita realizar acciones sobre la máquina vulnerable. Estas acciones o código ejecutado sería con permisos de root, lo cual hace que se ponga aún más interesante. 

En el blog de Reverse Engineering Mac OS X han publicado un artículo en el que se lleva a cabo la ingeniería inversa de la vulnerabilidad. La excusa para llevar a cabo la prueba de concepto es que Apple no informa mucho de sus actualizaciones de seguridad, no dicen si es explotable en instalaciones OS X por defecto o requiere condiciones particulares. Tras la lectura del artículo se puede ver como el error no es explotable en instalaciones OS X por defecto. La herramienta Diaphora creada por Joxean Koret permite obtener las diferencias entre un binario vulnerable y la actualización. El binaio de syslogd se encuentra en /usr/sbin/syslogd. En la imagen se puede ver como difiere en poco código.

Figura 1: Diferencias en los binarios syslogd vulnerable y actualizado

El código fuente de syslogd para OS X El Capitan 10.11.2 puede descargarse desde el dominio opensource.apple.com. El parche se encuentra realizado en el tamaño de asignación de reallocf(). El detalle del proceso de ingeniería inversa puede ser observado en el artículo, el cual recomendamos la lectura con una taza de café.

El lenguaje C es poderoso, pero pequeños errores pueden suponer la ejecución de código arbitrario, e incluso la escalada de privilegio. El programador de la pieza de código cometió un pequeño error, y su arreglo puede ser tan simple como el añadir un conjunto de parentésis. La función vulnerable se encuentra en add_lockdown_session(), y para llegar a ella se puede visualizar este árbol de funciones.

Figura 2: Árbol de llamadas en syslogd

Cómo se puede visualizar el proceso de ingeniería inversa puede ser una tarea altamente compleja. La vulnerabilidad en syslogd se encontraba en una función, la cual con la configuración por defecto de OS X no es vulnerable, pero que dicha vulnerabilidad estaba ahí. Como se menciona anteriormente se recomienda la lectura de todo el proceso de reversing llevado a cabo y estar atentos al mínimo detalle.

Ingeniería Inversa de aplicaciones iOS en un libro gratuito

La ingeniería inversa es un proceso importante para encontrar vulnerabilidad y conocer como funcionan ciertas apps internamente. Este proceso ayuda a los investigador a poder destripar el funcionamiento de las apps y poder encontrar errores de programación o de procedimiento. Los compañeros de Cyberhades nos hablan de este libro el cual nos llevará por un camino de 5 años en el que en el autor habla de sus experiencias en la comunidad Jailbreak.

El libro se organiza en 4 apartados, aunque su enfoque es eminentemente prático, ya que su temática así lo es. Los apartados que pueden encontrarse son los siguientes:

• Conceptos e introducción a la temática de la ingeniería inversa.
• Herramientas que se necesitan durante el desarrollo del libro y en el proceso de ingeniería inversa.
• Teoría. Aunque el libro es práctico se necesita de la teoría para llevar a cabo los ejercicios y ejemplos.
• Práctica. La mayoría del libro muestra ejemplos y formas prácticas de realizar las cosas.

Figura 1: Uso de IDA en el libro

Las herramientas utilizadas en el libro son las más comunes como Cycript, Reveal o IDA. Objective-C y ARM también disponen de una gran parte del libro, ya que sin este conocimiento no se podrían llevar a cabo diversas acciones. Si prefieres tener el libro en papel se puede conseguir por casi 10 dólares.

Análisis de ficheros SCAP (Secure Capsule) de Apple

Las actualizaciones de firmware de dispositivos Apple utilizan ficheros de tipo SCAP (Secure Capsule). Esta especificación de formato de ficheros es propietaria de Apple aunque se basa en la creada por Intel en el año 2003 para definir volúmenes de firmware. Los investigadores de seguridad cada vez están poniendo más los ojos en ellos, especialmente tras ThunderStrike o ThunderStrike 2, y nuestro compañero David Barroso ha hecho un análisis de ellos en su blog.

En su análisis explica no solo el formato que ellos tienen, sino como pueden ser analizados utilizando herramientas como UEFITool para comprobar el contenido y proceder con un análisis posterior. En este artículo están los detalles y la explicación. 

Figura 1: Apertura de un fichero SCAP de Apple con UEFITool

Si te gusta el mundo del reversing, y te atraen los esquemas APT, está claro que el firmware de los dispositivos es muy apetecible, sobre todo teniendo en cuenta que la mayoría de las herramientas de análisis de seguridad de de binarios suelen pasar por algo el contenido de este tipo de ficheros embebidos en el firmware.

Infiltrate: Writting Bad@s Malware & Objetive-C Explotation

La conferencia Infiltrate es un evento que la compañía Immunity realiza todos los años centrada en técnicas de seguridad ofensiva y explotación. Los vídeos de las charlas de este año fueron publicados y recogidos por nuestros amigos de Cyberhades, y entre ellos hay dos conferencias muy interesantes centradas en el mundo de las tecnologías Apple que, aprovechando que comienza el fin de semana, puede ser un buen momento para que las disfrutes con tiempo.

La primera de ella es Writting Bad@ss malware for OS X, la conferencia que tanto dio que hablar después en BalckHat y Defcon sobre cómo se puede crear un malware malo de verdad para los sistemas OS X. Este es el vídeo de la charla tal y como la dio en Infiltrate.

Figura 1:  Patrick Wardle Writing Bad@ss OS X Malware

El segundo de ellos es la conferencia de Neil Archibald centrada en Modern Objective-C Exploitation. Es decir, en cuáles son las técnicas más modernas para atacar aplicaciones escritas en Objetive-C.

Figura 2:Neil Archibald Modern Objective-C Exploitation

Si te gusta el exploiting de sistemas a bajo nivel, no dudes en perder un par de horas de tu vida disfrutando de ellas. Que tengáis un buen fin de semana.

JWiFi: Reversing & Porting de Apple80211 a iOS

El hacker Jonathan Levin ha publicado dos grandes artículos para los amantes de las tecnologías WiFi, el reversing y el mundo del hacking en general, analizando en profundidad el framework WiFi Apple80211 desde cero. Estos componentes son los responsables de todas las funcionalidades que tienen los sistemas OS X e iOS en la gestión de la red WiFi en las tecnologías Apple y que tienen muchas características ocultas.

Figura 1: Estructuras de Apple80211 WiFi

Al final del artículo, se propone hacer el porting de estas módulos a una librerías sin restricciones legales en el proyecto JWiFi para que se pueda utilizar en todos los sistemas. Estos son los dos artículos que no debes perderte.

- 11208elppA
- Apple 80211 - 28 Days Later (a.k.a 11201ellpA, Part II)

Explotando bugs en aplicaciones escritas en Objective-C

En el popular e-zine Phrack Magazine se han publicado dos artículos a explotar aplicaciones escritas en Objetive-C, como cuentan nuestros amigos de Cyberhades. El primero de ellos, que ya tiene un tiempo, está centrado en el Runtime de Objective-C, y bajo el título de The Objective-C Runtime: Understanding and Abusing explica cómo funciona y cómo se pueden explotar aplicaciones abusando de él.

Figura 1: The Objective-C Runtime: Understanding & Abusing

El segundo, y más reciente artículo, se titula Modern Objetive-C Exploitation Techniques y se centra en la explotación de bugs de corrupción de memoria y cómo generar exploits utilizando técnicas como ROP.

Figura 2: Modern Objetive-C Exploitation Techniques

Si te gusta el mundo del exploiting, y quieres centrarte más en las aplicaciones de iOS o de OS X creadas con Objetive-C merece la pena que estudies a fondo estos dos artículos.

Bypass a OpenSSL Certificate Pinning en aplicaciones iOS

Usar Certificate Pinning es una de las medidas de seguridad más empleadas para evitar los ataques de man in the middle con suplantación de certificados, tal y como hemos podido ver en el artículo del blog de Eleven Paths titulado "Certificate Pinning. El qué, el cómo y el porqué. Para tenerlo disponible existen diversas formas de implementarlo. Se puede utilizar HSTS, que es el camino optado por Google Chrome - a pesar de generar el problema de privacidad con las Super Cookies -, el sistema implementado de Certificate Pining por Mozilla Firevox, o la que utiliza EMET que es el camino utilizado en Microsoft Windows y para el que desde Eleven Paths publicamos la herramienta EMET Rules que ayuda a gestionar el Certificate Pinning en EMET.

Hoy queremos hablar de un artículo publicado por  Matasano donde se explica en detalle Cómo bypassear OpenSSL certificate pinning en aplicaciones iOS.

Certificate Pinning: Un resumen

A modo de resumen, comentar rápidamente que cuando una aplicación móvil se comunica con una API o un servicio en la web debe realizar dicha comunicación a través de TLS / SSL. El objetivo es verificar la identidad del servidor y prevenir los temidos ataques Man in The Middle. Los navegadores y sistemas operativos móviles vienen preconfigurados con una lista de entidades emisoras de certificados de confianza. Desde cualquiera de las CA de la lista se puede emitir un certificado para cualquier nombre de host o servidor. Las aplicaciones conscientes de la seguridad deben pinnear el certificado esperado en la aplicación, es decir, no aceptarán ningún certificado salvo el emitido por la CA conocida que utiliza el desarrollador de la aplicación. En el siguiente documento publicado en el Canal Slide en SlideShare de Eleven Paths se explica en detalle.

Figura 1: Contramedidas en la suplantación de autoridades de certificación. Certificate pinning

Cuando pensamos en un test de intrusión, disponer de Certificate Pinning puede ocasionar problemas para interceptar la comunicación de una aplicación en un proceso de auditoría de seguridad. Generalmente, sin pinning, la intercepción implica agregar el certificado TLS de un proxy, por ejemplo Burp o Zaproxy, al almacén de certificados del sistema operativo. Sin embargo, cuando la aplicación utiliza certificate pinning, el almacén es ignorado.

Evitar el Certificate Pinning para auditar una app en iOS

En iOS se dispone de la aplicación iOS SSL Kill Switch, la cual se puede utilizar para bypassear el pinning y forzar a que la aplicación acepte cualquier certificado presentado por un servidor o proxy. La aplicación utiliza Cydia Substrate, el cual hookea las funciones que iOS utiliza para la validación de certificados y las modifica para aceptar cualquier certificado. Este hecho es más complejo cuando se utiliza la librería OpenSSL, ya que no está afectada por este tipo de hooking. Hay más de una forma de bypassear OpenSSL based certificate pinning, lo cual puede estudiarse en un whitepaper escrito por Daniel Mayer, utilizando binary patching and in-memory hooking.

Figura 2: Bypass OpenSSL Certificate Pinning on iOS

En él se detalla un escenario en el cual se crea un mock-up de una aplicación iOS que utiliza OpenSSL y realiza pinning. La aplicación realiza una conexión a https://www.example.org y realiza una petición GET a la raíz del sitio. Existen dos tipos de ejecutables en esta prueba, ARMv7 y ARMv8, y accesibles en el Github dónde se encuentra la app. El dispositivo debe tener realizado el jailbreak para poder realizar este proceso, por supuesto.

En primer lugar redirigen el tráfico de la app al Burp. Una de las maneras sencilla que exponen es  modificar el fichero /etc/hosts introduciendo la línea 127.0.0.1 www.example.org, para que resuelva a un servidor que se encuentra en local. Una vez realizado esto, se puede realizar un SSH forwarding para reenviar tráfico desde el puerto 443 del dispositivo al puerto 8080 sobre nuestra máquina dónde esta Burp a la escucha en modo trasparente.

Figura 3: Port Forwarding

La aplicación intentará conectarse al proxy pero la conexión fallará debido al certificate pinning. En el proxy se puede leer el mensaje "The client failed to negotiate an SSL connection to www.example.org:443", tal y como se puede ver en la imagen.

Figura 4: Fallo por Certificate Pinning

Analizar el pinning es una de las primeras cosas que hay que hacer. En este caso la app utiliza como pinning una lista restringidas de CAs. La aplicación genera dinámicamente certificados con OpenSSL  y son almacenados en memoria. El listado de CAs son hardcodeadas en el código fuente de la aplicación, en formato PEM.

En general, esto es bastante común para almacenar CAs en el sistema de archivos y sería una acción natural hacerlo igual para pinear certificados en aplicaciones móviles. Una desventaja de este enfoque es que los certificados pueden ser fácilmente cambiados en un dispositivo con Jailbreak. Sin embargo, los certificado que viven en el binario son más dificiles de cambiar, ya que se tiene que modificar el binario para hacerlo.

Figura 5: Certificados hard-codeados en formato PEM

Dada esta configuración se puede intercambiar el certificado en el binario o deshabilitar la validación del certificado de otra manera. El intercambio de certificados es un reto ya que los diferentes certificados tienen diferentes longitudes y el espacio en el binario dónde se encuentran los certificados originales pueden no ser suficientes. Los grandes cambios en los binarios pueden ser poropensos a errores. La validación de certificados utiliza SSL_CTX_set_verify, por lo que se tiene que convertir su valor en SSL_VERIFY_NONE para deshabilitar la validación, con el pinning se encuentra en SSL_VERIFY_PEER. Hacer este cambio hace que la firma de la aplicación se rompa, por lo que se debe utilizar un dispositivo con Jailbreak, para no verificar las firmas.

Por último, se puede ver cómo decompilar la aplicación con herramientas como dumpdecrypted. Además se contempla como hacer el proceso para binarios compilados en ARMv7 y ARMv8.

Figura 6: Certificate Pinning bypasseado

Certificate Pinning es una técnica útil para proteger contra ataques de MiTM, o para asegurar que los proxies corporativos que interceptar tráfico TLS no pueden acceder a dicho tráfico de las aplicaciones. A través de iOS SSL Kill Switch, manual crypt hooking o binary patching como se describe en este trabajo, se podría hacer una auditoría de una app que tenga esta medida de seguridad activada.

Hopper: Debugger para ingeniería inversa en OS X & Linux

Hoy domingo, por si estás con algo de tiempo libre y quieres dedicarlo a aprender algo nuevo, o comenzar con un camino distinto, como por ejemplo el reversing de binarios que es tan útil en los CTF de las conferencias de hacking, vamos a a hablaros de una herramienta que seguro que os viene bien tener en vuestro OS X. Hopper es una herramienta que nos permite realizar un análisis estático de los ficheros ejecutables. Es decir, nos va a permitir realizar debugging sobre los binarios, con lo que podremos jugar y saber como funciona. Se debe poder conocer qué instrucciones está ejecutando un binario para poder saber que está haciendo realmente en el sistema.

La interfaz de Hopper es bastante intuitiva si estás metido en el mundo de la ingeniería inversa. Principalmente consta de tres áreas:

• El panel izquierdo contiene una lista de todos los símbolos definidos en el archivo y cadenas de la lista. La lista se puede filtrar utilizando etiquetas y texto. 
• El panel derecho, denominado Inspector, contiene información contextual sobre el área que está siendo explorada.
• La parte central de la aplicación es dónde se muestra el lenguaje ensamblador.

Figura 1: Interfaz de Hooper para la visualización de código debuggeado

Hopper permite asignar nombres o símbolos a las direcciones, para tener un recordatorio más sencillo y eficaz de partes de código interesantes. Otra característica interesante es que permite la navegación por el stack de manera sencilla e intuitiva. La barra de navegación permite al usuario disponer gráficamente mediante el uso de una línea de las diferentes partes de la aplicación. El índice de colores utilizado es el siguiente:

• Color azul para representar las partes de código.
• Color amarillo para representar procedimientos.
• Color verde para representar los ASCII strings.
• Color púrpura para representar zona de datos.
• Color gris para representar una zona indefinida.

Figura 2: Índice de colores para conocer cantidades de tipos de datos en el binario analizado

Otra de las cosas que nos han gustado es la exportación de los gráficos a PDF y como la información es presentada mediante el CFG, Control Flow Graph. Se puede mover los bloques de la gráfica, y haciendo doble click en un bloque se navega hasta las instrucciones correspondientes, las cuales se presentan en la parte central de la herramienta.

Figura 3: Gráfico de Flujo de Control en Hooper sobre un binario analizado

Se recomienda que si eres un inquieto del mundo Apple y te gusta la ingeniería inversa pruebes la herramienta. No es gratuita, pero proporciona un período de prueba con el que podrás ver las características interesantes que proporciona antes de decidir si merece la pena hacer la inversión. A nosotros nos ha gustado.

iRET: iOS Reverse Engineering Toolkit

A través de nuestros amigos de Cyberhades hemos conocido iOS Reverse Engineering Toolkit, un paquete con un conjunto de herramientas comúnmente utilizadas para analizar la seguridad de apps para iOS que han sido paquetizadas para ser usadas de forma cómoda.

Figura 1: Página de inicio de iOS Reverse Engineering Toolkit

El toolkit permite analizar de forma cómoda una serie de operaciones sobre cualquier app, como son:

- Binary Analysis (basado en otool)
- Keychain Analysis (keychain_dumper)
- Database Analysis (sqlite3)
- Log Viewer
- Plist Viewer
- Header Files
- Crear, editar, guardar y construir tweaks para theos
- Display screenshots cacheadas

La herramienta permite analizar, por ejemplo, los keychains de una app, o ver cómo se realiza la gestión de datos en las bases de datos SQLite, todo de forma automatizada.

Figura 2: Análisis de Keychains con iRET

Para poder hacer funcionar este toolkit, además de bajarte el paquete iRET necesitas instalar las siguientes dependencias:

Python (2.5.1 or 2.7)
adv-cmds
Bourne-Again Shell
iOS Toolchain (coolstar version)
Darwin CC Tools (coolstar version)
An iOS SDK (de iOS 6.1 or 7.x) instalado en /theos/sdks

Aquí en Seguridad Apple, ya os hemos hablado de algún otro framework automatizado para el análisis de apps para iOS, como por ejemplo iNalyzer, y lo importante es que el auditor sepa qué es lo que busca y se sienta cómodo con él.

OSX/Crisis.C: Un malware para OS X llamado Francisco

Dese Intego informan de que vía Virus Total se ha distribuido una nueva muestra de malware detectada para sistemas Mac OS X. Se trata de una nueva variación del malware OSX/Crisis que viene el rootkit Da Vinci de la empresa Hacking Team. Esta pieza de malware es una mutación que venía un fichero llamado "Frantisek", que al final es el nombre de Francisco en los países de la Europa del Este. Como todas las muestras de OSX/Crisis se instala vía dropper que descarga el rootkit y como en las últimas muestras funciona en Mac OS X 10.5, 10.6 y OS X 10.7 Lion, pero crashea en OS X  Mountain Lion y Mavericks.

En la parte referente al dropper parece que Hacking Team ha cambiado un poco el código y el formato del fichero de configuración, ya que según el análisis realizado por Intego ahora utilizar un segmento de código que no aparece en previas muestras, llamado __INITSTUB, que es llamado antes de ejecutarse la función _main del programa, algo que haría que un ingeniero de reversing con poca experiencia pudiera infectarse antes de llegar al main del programa.

Figura 1: Símbolos de OSX/Crisis.C obtenidos con IDA

Según el análisis que han hecho los ingenieros de Intego, cuando OSX/Crisis.C consigue ejecución se oculta en la carpeta del perfil de usuario que está en la ruta ~Library/Preferences, dentro de una falsa aplicación que tiene como nombre del bundle OvzD7xFr.app. Los ficheros que se crean dentro son:

El fichero del backdoor: 8oTHYMCj.XIl (32-bit)
Fichero de configuración : ok20utla.3-B
Extensiones del kernel: Lft2iRjk.7qa (32-bit) y 3ZPYmgGV.TOA (64-bit)
Script de adición: EDr5dvW8.p_w (FAT)
Servicio XPC: GARteYof._Fk (FAT)
Icono TIFF de Preferencias del Sistema.TIFF: q45tyh

Cuando el malware consigue ejecución entonces se crea un LaunchAgent llamado com.apple.mdworker.plist para conseguir las persistencia en el sistema. Al igual que OSX/Crisis.B esta muestra está ofuscada con el packer MPress y aunque tiene pequeños cambios sigue funcionando como las versiones anteriores, tal y como explican en Intego, se oculta a si mismo modificando la aplicación del Monitor de Actividad, toma capturas de pantalla, graba audio y vídeo por la webcam, extrae datos del usuario, su ubicación GPS, se conecta a redes WiFi y sincroniza todos los datos con un panel de control del que recibe las ordenes.

No se sabe muy bien cómo o por donde se está distribuyendo, ya que este tipo de piezas de software suelen usarse para ataques dirigidos, pero merece la pena conocer cómo funcionan estas muestras para estar siempre alerta y mantener el sistema protegido.

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.

iNalyzer: Un framework para analizar aplicaciones iOS

Dentro de la revista de Hack in the Box Magazine #10 - de la que hablamos hace poco por aquí sobre el artículo de cazar rootkits de Mac OS X en memoria - hay otro interesante artículo que merece la pena destacar. En este caso es sobre iNalyzer, un framework para analizar apps de iOS de forma cómoda y eficiente. La idea de iNalyzer es conectar el un equipo con el terminal iOS para poder ejecutar las aplicaciones de auditoría a las que están acostumbrados los pentesters, como pueden ser Burp Intruder, los editores de todos los formatos o las herramientas de debuging en tiempo real.

El artículo se encuentra al final de la revista, pero se basa en una presentación que se hizo en OWASP 2012 en Israel por la empresa AppSec, que puede ser descargada desde aquí. El framework de iNalyzer necesita una app que puede ser descargada desde Cydia gratuitamente, por lo que necesariamente se necesita contar con un terminal con Jailbreak para correr este entorno de auditoría.

Figura 1: Análisis de apps para iOS con iNalyzer

En el siguiente vídeo se puede ver una pequeña demostración de como iNalyzer se utilizar para saltarse en tiempo real la pantalla de Login de iSafePlay, haciendo un bypassing de la autenticación en tiempo real.

Figura 2: Con iNalyzer haciendo un bypass de login a iSafePlay

Si te dedicas o quieres dedicarte a analizar la seguridad de apps de iOS, debes echarle un vistazo sin duda, pues ofrece utilidades que tal vez puedan ayudarte o completar el arsenal de ellas que ya tengas.

Cómo cazar rootkits de Mac OS X en la memoria

En la revista Hack in the Box Magazine número 10 se ha publicado un buen artículo para los amantes de la ingeniería inversa titulado: "Hunting for OS X rootkits in memory". La revista está para descarga gratuita, así que os recomendamos que la descarguéis y le deis una buena lectura si os gusta este mundo. Si quieres sacar el máximo partido a ese artículo, sería bueno que entiendas cómo se construyen los rootkits para Mac OS X, así que dale un buen repaso a la conferencia y el material de Pedro Vilaca titulada "Revisiting Mac OS X Kernel Rootkits".

En este artículo en concreto, escrito por Cem Gurkok se proporcionan no solo técnicas, sino también scripts para hacer los volcados de las las tablas de objetos en memoria para poder analizar lo que está pasando en el sistema y localizar lo que puede que se esté ejecutando y esté oculto, así que si tienes tiempo y ganas de aprender ya sabes qué puedes hacer este fin de semana.

Figura 1: Script para ocultar procesos en memoria y luego localizarlos

Sobre este tema, recuerda también que si quieres analizar aplicaciones sospechosas en Mac OS X os hablamos hace tiempo de cómo usar los Instruments con Dtrace para saber cuales son las acciones que realiza en el sistema, y que puedes usar y analizar el funcionamiento de la herramienta de OS X Rootkit Hunter de Christian Homung.