Artículo original escrito por Christopher Vance (@cScottVance). Traducción al español por Geraldine Blay (@i_am_the_gia).
En el sistema operativo iOS, una de las cosas más irritantes que he encontrado cuando trabajo con data o cuando ayudo a un estudiante es el intentar rastrear que aplicación es responsable de colocar data en cierto lugar en específico. Gracias al gran trabajo realizado por otros, incluyendo Alexis Brignoni (enlace aquí),ApplicationState.db (como parte del directorio de FrontBoard) siempre ha sido uno de los primeros lugares que frecuento cuando construyo un “mapa del tesoro” de las aplicaciones. Esta base de datos nos ayuda a poder lidiar con los AppGUIDs fastidiosos que Apple le asigna a cada app.
Estos AppGUIDs molestosos de los que estoy hablando se pueden encontrar en:
/private/var/mobile/Containers/Data/Application
Afortunadamente, la mayoría de las herramientas procesan ApplicationState.db y relacionan cada uno de los identificadores únicos (AppGUIDs) con sus respectivas aplicaciones.
¡Grandioso! Esta es una manera mucho más sencilla de identificar donde “viven” cada una de esas aplicaciones. Sin embargo, a veces encuentras un archivo de interés dentro de un directorio y necesitas hallar una correspondencia entre el directorio y esta base de datos. Quizás te encuentras en una situación en la que solo tienes la imagen y acceso muy limitado a herramientas. ¿Cómo podemos encontrar el bundleID de la aplicación dentro del directorio?
Dentro del directorio de la aplicación debe de haber un archivo llamado ".com.apple.mobile_container_manager.metadata.plist" (este nombre parece ser el mismo dentro del directorio de cada aplicación). Este archivo de tipo plist contiene claves con el bundleID de la aplicación, lo que es fenomenal si te encuentras en apuro y no quieres saltar de una localización a otra.
Lo más interesante es lo que ocurre cuando realizas una búsqueda con el nombre de este archivo a lo largo de la imagen del dispositivo iOS. Si haces esto, notarás que hay archivos nombrados .com.apple.mobile_container_manager.metadata.plist en muchos lugares, incluyendo:
· /private/var/containers/Bundle/Application/APPGUID/
· /private/var/containers/Shared/SystemGroup/APPGUID/
· /private/var/containers/Data/System/APPGUID/
· /private/var/mobile/Containers/Shared/AppGroup/APPGUID/
· /private/var/mobile/Containers/Data/Application/APPGUID [¡obviamente!]
· /private/var/mobile/Containers/Data/InternalDaemon/APPGUID/
· /private/var/mobile/Containers/Data/PluginKitPlugin/APPGUID/
¡Caramba! Esos son muchos lugares que tenemos que explorar para poder realizar nuestro mapa del tesoro. A fin de cuentas, ¿qué es este archivo? Primero, vamos a hablar de “sandboxing” (o aislamiento de procesos y aplicaciones). Apple utiliza “sandboxing” mucho en el sistema operativo iOS. Esto es para prevenir que las aplicaciones tengan acceso a data que no se supone que accedan por motivos de seguridad. Se le otorga a cada aplicación un “sandbox” y solo pueden jugar en ella. .com.apple.mobile_container_manager.metadata.plist nos permite ver que en que “sandbox” nos encontramos y a qué aplicación le pertenece ese “sandbox”. Utilizando esta información, podemos desglosar un poco más la localización del directorio que habíamos identificado para poder entender por qué ciertas aplicaciones guardan la data en ciertos lugares.
/private/var/containers/Bundle/Application/
Este es el directorio que contiene el .app, así como información adicional sobre la aplicación, y quién la descargó. Además del .app, el directorio contiene dos plists (iTunesMetadata y BundleMetadata) que guardan información que pudiera ser útil, como cuándo se descargó la aplicación, qué versión de la aplicación se descargó, y cuál AppleID se utilizó para descargarla.
/private/var/containers/Shared/SystemGroup/
Este directorio es similar al que listamos arriba, pero aplica a las aplicaciones principales del dispositivo iOS. Este directorio contiene menos información, pero también contiene un archivo .plist que muestra qué aplicación del sistema corresponde a este contenedor.
/private/var/containers/Data/System/
Este directorio también es similar al directorio discutido arriba, pero parece contener aplicaciones del sistema que no quieren compartir información con otras aplicaciones principales. No contiene información de mucha relevancia, con excepción del bundleID que indica qué aplicación es dueña del contenedor.
/private/var/mobile/Containers/Shared/AppGroup/
Aquí es donde en realidad comienza la diversión. Anteriormente mencioné el “sandboxing”. Apple indica que a las aplicaciones no se les permite compartir información sin pedirla a través de canales oficiales. Para poder compartir información, los desarrolladores de las aplicaciones asignan un “grupo” a su aplicación. De acuerdo con la documentación para desarrolladores publicada por Apple, estos grupos pueden compartir data entre ellos. Puede ser que hayas visto algo similar listado como “AppDomainGroup-group.bundleID” en vez de “AppDomain-com.bundle.ID” al analizar una imagen estilo “backup”. Con frecuencia he utilizado este directorio cuando no puedo encontrar la data que estoy buscando en el directorio principal de Application Data.
Ahora hablemos de la desventaja… El ApplicationState.db no contiene información sobre la localización de este directorio. ¿La ventaja? El directorio “Shared/AppGroup” de cada aplicación va a contener uno de nuestros archivos .com.apple.mobile_container_manager.metadata.plist. ¡Woohoo!
Mejor aún, Alexis Brignoni ha añadido soporte en iLEAPP para crear una lista de todos los archivos de este directorio. Esto nos permite establecer una relación entre el contenido del archivo y la localización del directorio correspondiente. [Descarga iLEAPP aquí]
Una aplicación también puede tener más de un directorio en esta localización. Por ejemplo, la aplicación de Dropbox tiene más de 4 contenedores distintos aquí, y la aplicación de correo electrónico de Spark tiene 2. Más importante aún, algunas aplicaciones pueden almacenar toda su data relevante aquí en vez de en /private/var/mobile/Containers/Application/Data/. Un ejemplo de esto es la aplicación de Spark (enlace de iTunes en la red), la cual almacena todas sus bases de datos relevantes en /private/var/mobile/Containers/Shared/AppGroup/en vez de en /private/var/mobile/Containers/Application/Data/, que por lo general es una estructura de directorio mas común. [Otros ejemplos notables de esto incluyen WhatsApp y Signal]
/private/var/mobile/Containers/Application/Data
Este es el lugar donde “se supone” que miremos para encontrar data de las aplicaciones. Este directorio esta bien documentado y estudiado dentro del campo de la informática forense. Sin embargo, puede ser que no sea aquí donde encontremos lo que necesitamos, a fin de cuentas.
/private/var/mobile/Containers/Application/InternalDaemon
En mis dispositivos de prueba, este directorio parece contener servicios de Apple (o internal “daemons”, obviamente, como indica el nombre) que pueden ser rastreados utilizando los archivos .com.apple.mobile_container_manager_metadata.plist.
/private/var/mobile/Containers/Application/PluginKitPlugin/
Recientemente me he topado con dos situaciones en las que he estado asistiendo a estudiantes y hemos acabado encontrando data crucial dentro de este directorio. Establecer una relación entre la data que se encuentra aquí puede ser difícil, pero ha rendido fruto en varias situaciones.
Como Apple permite a las aplicaciones utilizar funcionalidades añadidas o “plugins” (por ejemplo, el teclado de Giphy, que es mi favorito), estos “plugins” pueden almacenar data dentro de este directorio. En un caso de prueba, se intentó identificar por qué muchos videos ilegales aparecían dentro de un directorio en especifico. Utilizando el archivo .com.apple.mobile_container_manager.metadata.plist, el analista pudo identificar qué “plugin” estaba colocando la data en este directorio, y cual era el bundleID correspondiente. En este caso se encontró que estaba relacionado al PhotoMessagesApp de com.apple.mobileslideshow.
Nota: com.apple.mobileslideshow es la aplicación de Fotos en iOS.
Ahora que sabemos a qué “plugin” y aplicación pertenece el directorio, podemos tratar de generar data de prueba para verificar cómo esta información llegó ahí. En mi ejemplo, utilicé el “plugin” de “photo picker” dentro de iMessage y modifiqué el video desde dicho “plugin” sin lanzar la aplicación original de com.apple.mobileslideshow. Utilizando KnowledgeC, podemos ver en las siguientes capturas de pantallas que el momento en que estos archivos fueron creados dentro del directorio de PluginKitPlugin/APPGUID/ coincide con la aplicación de MobileSMS.
He visto otros “plugins” como com.apple.mobileslideshow.photo-picker en algunas investigaciones pero a veces es difícil entender cómo se han poblado estos directorios sin tener acceso a KnowledgeC o PowerLog para ver la perspectiva completa. Pudiendo descifrar qué BundleID corresponde a cada directorio, tenemos al menos un punto de partida para poder entender cómo la data llegó al lugar donde está.
Ahora tenemos una mejor manera de poder construir nuestros “mapas del tesoro” y sabemos que los archivos .com.apple.mobile_container_manager.metadata.plist por lo general van a contener nuestro punto clave para encontrar el mismo.
No comments:
Post a Comment