Seguridad en aplicaciones IOS, Parte II

Continuación de Parte I.

El siguiente paso es descifrar el binario, ya que cuando un desarrollo es terminado por sus autores y enviado a Apple para añadirlo a la Apple Store, este es analizado y examinado. Si supera los tests, será cifrado y firmado, complicando que se haga ingeniería inversa sobre el.

Para descifrarlo tan solo hay que ejecutarlo y con gdb se vuelca la memoria del proceso. Tal y como se haría genéricamente para desempacar un binario en otra plataforma.

Antes de hacer esto, es recomendable que se conozca un mínimo la estructura de un binario Match-O, que en muy grandes rasgos se representa en este gráfico:

• El fichero contiene una cabecera donde se identifican distintos aspectos como si es fat o en la arquitectura en la que corre. 
• Tras la cabecera se encuentran los comandos, en los que se definen otras características como la localización de la tabla de símbolos, o los nombres de las librerías compartidas que son importadas en su ejecución.
• Finalmente los datos que son divididos en segmentos y estos en secciones. Los dos segmentos más importantes son:
• __TEXT, donde se encuentra el código de la aplicación y otros datos de solo lectura y 
• __DATA, donde la aplicación podrá escribir e intercambiar datos.

Volviendo al binario, para comprobar si está cifrado se puede consultar si el flag "cryptid" del comando LC_ENCRYPTION_INFO es igual a 1, además de otros valores como el tamaño del bloque cifrado "cryptsize"

Con la herramienta otool se obtienen estos valores:

iPhone:~ root#  otool -l /private/var/mobile/Applications/58ED43CF-0D53-4DDC-864C-7F34D34E059C/StupidZombiesDLX.app/StupidZombiesDLX | grep crypt
 cryptoff  8192
 cryptsize 10133504
 cryptid   1

Como se va a descifrar el binario, hay que cambiar el valor de cryptid a 0, para esto es necesario parchearlo modificando la cadena del comando LC_ENCRYPT_INFO, que contiene los valores: 0000002100000014......................01 por 0000002100000014......................00, donde los puntos representan valores (11) que pueden variar.

La forma más sencilla de cambiar este byte es copiando el binario con DiskAid a la estación de trabajo para usar editor hexadecimal, buscar por la cadena hexadecimal 0000002100000014, contar 11 bytes más y modificar el 01 por 00. Guardar y dejar el fichero en el iPhone en un fichero temporal.

Otra opción es leer la cabecera del fichero en hexadecimal, hacer la modificación y  posteriormente guardarlo en un fichero. Esto se puede hacer con estos dos comandos dentro del teléfono:

iPhone:/tmp root# hex=`dd bs=4096 count=1 if=/private/var/mobile/Applications/58ED43CF-0D53-4DDC-864C-7F34D34E059C/StupidZombiesDLX.app/StupidZombiesDLX 2>/dev/null| od -A n -t x1 -v  | tr -d ' ','\n' | sed -e 's|0000002100000014\(.\{22\}\)01|0000002100000014\100|' | sed -e 's|\(..\)|\\\\x\1|g'`
iPhone:/tmp root# echo -ne "$hex" > /tmp/header.hex

Se verifica que cryptid ahora es igual a 0:

iPhone:/tmp root# otool -l /tmp/header.hex | grep -i crypt
          cmd LC_ENCRYPTION_INFO
 cryptoff  8192 (past end of file)
 cryptsize 10133504 (past end of file)
 cryptid   0

WIN!

Si aun no te has cansado, continuamos la semana que viene con las instrucciones necesarias para el volcado final.

Graves vulnerabilidades en Wordpress 3.3.1 y anteriores

Jonathan Claudius, miembro del equipo de seguridad SpiderLabs perteneciente a la compañía Trustwave, ha publicado una nota de seguridad (o advisory) en la que presenta graves vulnerabilidades que afectan al gestor de contenidos Wordpress, para versiones 3.3.1 y anteriores.

Entre las vulnerabilidades tenemos Cross-Site Scriptings persistentes, Cross-Site Scriptings no persistentes ejecución de código PHP, fuga de información sensible de la configuración de la base de datos MySQL, ya que se permiten hacer consultas para averiguar el usuario y la contraseña sin tener límite de intentos. Todo esto es posible gracias al fichero de configuración de la instalación setup-config.php, que permite la instalación de Wordpress en bases de datos MySQL tanto locales como remotas. Si bien este script no puede ejecutarse si no se posee un usuario y contraseña válidos para el servidor MySQL...¿qué pasaría si configuráramos el Wordpress para que utilizase una base de datos propia, en vez de la original del servidor? Pues que a partir de ahí, "estamos vendidos".

Todo esto se ve claramente en el proceso descrito en el advisory, en el cual se presentan pruebas de concepto para las peticiones necesarias, y como aprovecharse de las vulnerabilidades encontradas para engañar a la instalación para que use nuestra base de datos, en vez de la original. Una vez el gestor de contenidos tiene configurada la base de datos para que conecte con una que hayamos alojado en un sitio accesible, podríamos inyectar código PHP mediante el editor de Temas incluído en Wordpress, o incluir código Javascript en el contenido o páginas del sitio, consiguiendo un Cross-Site Scripting persistente.

En la prueba de concepto, se detallan los siguientes pasos necesarios para el compromiso de un sistema Wordpress:

1) Configurar una base de datos MySQL en una dirección IP a la que tengamos acceso, y se tenga acceso desde el exterior. A esta base de datos es a la que apuntaremos para que se utilice como principal.

2) Peticiones contra el script vulnerable, "setup-config.php", modificando parámetros y valores de las peticiones POST (hacia setup-config.php) y GET (se llama a install.php para que realice la instalación) necesarias que configuren el Wordpress para conectar con nuestra base de datos.

3) Una vez se ha instalado el sistema Wordpress, se pueden realizar los dos tipos de ataques:

3.a) Ejecución de código PHP: Tras completar la instalación, se accede al editor de temas del sitio, y se modifica cualquiera de las plantillas para incluir código PHP, que se ejecutará al acceder a cualquier página construída con dichas plantillas (por ejemplo, y como se muestra en la prueba de concepto, la correspondiente con el aviso de página no encontrada, el 404.php)

3.b) Cross-Site Scripting persistente: Petición en la base de datos (que recordemos, tenemos el control por ser directamente nuestra) para actualizar contenido del blog e incluir una cadena de texto JavaScript.

Tenéis más información sobre estas acciones, además de los Cross-Site Scriptings no persistentes y la posible fuga de información de usuario y contraseña de MySQL realizando fuerza bruta, en la nota de seguridad TWSL2012-002 de Trustware

Y para acabar, vamos con la respuesta por parte del equipo de Wordpress, cuando se les notificó estos problemas: "Damos prioridad a tener una mejor experiencia del usuario en el proceso de instalación. No es muy corriente que un usuario se encuentra con el problema de instalar una copia de Wordpress y no finalizar el proceso de configuración de la instalación de forma inmediata. Las posibilidades de explotar dicha vulnerabilidad son muy pequeñas."

Todos más tranquilos, ¿verdad? Menos mal que seguro que no nos encontramos en ningún sitio un Wordpress cuyos archivos han sido subidos, y todavía no han comenzado la instalación.

[+] TWSL2012-002: Multiple Vulnerabilities in WordPress [blog de SpiderLabs]

Seguridad en aplicaciones IOS, Parte I

Después de un tiempo perdido en el espacio dedicando todo mi tiempo y esfuerzo a las auditorias en entornos móviles de varios clientes, vuelvo para ver un tema que hemos tratado poco: la seguridad de aplicaciones en iPhone.

En esta primera serie de entradas voy a explicar el caso más sencillo para hacer una auditoria de caja negra sobre la aplicación, ya que con la aparición del iPhone 3GS y la versión 4.3 de  IOS esta tarea se complica un poco más.

Para seguir este mini tutorial básico, se necesita disponer de un iPhone jailbreakeado con los siguientes paquetes de cydia instalados: OpenSSH, adv-cmds, Erica Utils, Darwin CC Tools, ldone, Gawk, developer-cmds, odcctools y com.ericasadun.utilities, opcionalmente: sqlite3, syslogd, class dump y tcpdump.

Si además vuestro terminal tiene IOS 5, deberéis descargar esta versión del debugger GDB y almacenarla en el directorio /usr/bin. Si por el contrario es inferior, se puede instalar el paquete GNU Debbuger de cydia.

En cuanto a la estación de trabajo, es recomendable tener un editor hexadecimal, un cliente de SSH y una aplicación que permita acceder al directorio root del sistema de ficheros del teléfono, como DiskAid o iFunBox. No vamos a entrar en detalles de cómo se instala todo esto, en casi todas es "next, next, finish" y poco más. Es importante que seamos capaces de hacer un SSH al móvil.

Una vez listos, se procede a buscar una aplicación candidata. Como se ha contado anteriormente, de momento será la más sencilla.

Existen dos complicaciones "nativas", es decir, sin contar con que el desarrollador haya incluido ninguna protección adicional.  La primera viene a raíz del nacimiento del iPhone 3GS, donde cambian el procesador de un ARMv6 a ARMv7 y esta modificación requiere que los binarios  Match-O pasen de ser sencillos a binarios fat, lo que significa que  que incluyen juegos de instrucciones para varios procesadores.

La siguiente complicación es la actualización a IOS 4.3, donde se incluye  una característica de seguridad ya común en otros sistemas operativos: ASLR (address space layout randomization). Aunque su implantación es parcial si la aplicación no es compilada con PIE (position-independent executable).

Este primer experimento se hará con un binario que no sea fat y sin soporte completo de ASLR. La experiencia dice que encontrar binarios simples es complicado, pero que no tengan el soporte completo  es bastante sencillo. ¡Vamos a buscar una!

Las aplicaciones se encuentran en unos directorios llamados "bundles" y su ruta es  /var/mobile/Applications/*/*.app/, dentro de cada uno de estos directorios están los recursos necesarios para su funcionamiento.

Cada aplicación almacena información en un archivo del tipo property list, llamado "Info.plist"  que puede ser XML o binario y que se consulta con la herramienta de comandos plutil, incluido en el paquete com.ericasadun.utilities o con un simple editor de textos.

Con plutil -key se consultan los valores que dan información sobre la aplicación, algunas claves útiles son:

• CFBundleExecutable: nombre del ejecutable.
• CFBundleDisplayName: nombre que se muestra de la aplicación.
• CFBundleName: nombre de la aplicación.
• CFBundleVersion: versión de la aplicación.
• CFBundleShortVersionString: versión corta de la aplicación.
• MinimumOSVersion: versión de IOS necesaria.
• UIRequiredDeviceCapabilities: requerimientos hardware del dispositivo, como armv7, o acelerometro, teléfono, wifi, etcétera.
• UIDeviceFamily: si devuelve 1 es software para iPad si devuelve un 2, es compatible con iPad e iPhone.

Y también el archivo plist "iTunesMetadata.plist":

• itemName: nombre de la aplicación en iTunes.
• artistName: nombre de la compañía que ha creado el software.

Por ejemplo, de Waze se sacan estos datos:

iPhone:~ root# plutil -key CFBundleExecutable /private/var/mobile/Applications/C3178EAC-0E19-43A7-A92C-994438E59835/Waze.app/Info.plist
Waze
iPhone:~ root# plutil -key MinimumOSVersion /private/var/mobile/Applications/C3178EAC-0E19-43A7-A92C-994438E59835/Waze.app/Info.plist
4.0
iPhone:~ root# plutil -key UIDeviceFamily /private/var/mobile/Applications/C3178EAC-0E19-43A7-A92C-994438E59835/Waze.app/Info.plist

(
    1,

    2
)

Ahora se muestra que binarios son fat y cuales no dentro de los que tenemos instalados para hacer la prueba. La forma más rápida es utilizar el comando "file", que comprobará la cabecera del fichero y si comienza con el magic "cafebabe" .

iPhone:~ root# IFS='
'
iPhone:~ root#  for i in `ls -d /var/mobile/Applications/*/*.app 2> /dev/null | sort -f -t \/ -k 6` ; do b=`plutil -key CFBundleExecutable $i/Info.plist`; file $i/$b; done

/var/mobile/Applications/B78EB987-6D05-4B5A-8C15-053565934EBA/Twitter.app//Twitter: Mach-O fat file with 2 architectures
/var/mobile/Applications/9729C704-D0FA-47A0-82D0-D9528688A61D/Viber.app//Viber: Mach-O fat file with 2 architectures
/var/mobile/Applications/C3178EAC-0E19-43A7-A92C-994438E59835/Waze.app//Waze: Mach-O fat file with 2 architectures
/var/mobile/Applications/F6CF4CAE-1B55-4516-9CDF-98BCBFE72E37/Rapid.app//Rapid: Mach-O executable acorn

Aunque también se puede sacar con un simple "dd" que lea los primeros bytes y "od" para convertirlos a hexadecimal, si devuelve el magic "ca fe ba be", tenemos un fat binary:

iPhone:~ root# dd bs=4 count=1 skip=0 if="/var/mobile/Applications/C3178EAC-0E19-43A7-A92C-994438E59835/Waze.app//Waze" 2> /dev/null | od -A n -t x1 -v | grep "ca fe ba be"
 ca fe ba be
iPhone:~ root# dd bs=4 count=1 skip=0 if="/var/mobile/Applications/F6CF4CAE-1B55-4516-9CDF-98BCBFE72E37/Rapid.app//Rapid" 2> /dev/null | od -A n -t x1 -v | grep "ca fe ba be"
iPhone:~ root#

El soporte ASLR completo, es decir, si se ha compilado con PIE, se consulta de forma similar, buscando el hexadecimal 20 en la posición del byte 26 del binario:

iPhone:~ root# dd bs=1 count=1 skip=26 if="/var/mobile/Applications/F6CF4CAE-1B55-4516-9CDF-98BCBFE72E37/Rapid.app//Rapid" 2> /dev/null | od -A n -t u -v
          0
iPhone:~ root# dd bs=1 count=1 skip=26 if=/private/var/stash/Applications/MobileSafari.app/MobileSafari 2>/dev/null | od -A n -t x1 -v
          20

La herramienta "otool" usada para trabajar con binarios Match-O, también puede facilitar esta información, identificando el flag "PIE" al final de la línea.

iPhone:~ root# otool -hv /private/var/stash/Applications/MobileSafari.app/MobileSafari

/private/var/stash/Applications/MobileSafari.app/MobileSafari:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
   MH_MAGIC     ARM          9  0x00     EXECUTE    43       5004   NOUNDEFS DYLDLINK TWOLEVEL PIE

¡¡Y todo esto solo para identificar una aplicación!! Bueno, realmente con este ejercicio se han visto muchas otras cosas.

Continuaremos muy pronto en las siguientes partes.