El misterioso caso de las manzanas podridas (IV)

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

Según lo visto en la entrada anterior (ver parte I, parte II y parte III), teníamos a nuestra disposición las siguientes evidencias digitales:

  • Volcado lógico de un iPhone5.
  • Volcado físico de un Samsung Galaxy S5.
  • Imagen forense de un Apple MacBook Pro.

La situación es casi la misma que en el caso de R.G, solo que con un portátil de Apple en lugar de uno de HP. El tratamiento de los móviles va a ser exactamente el mismo, así que nos ponemos rápidamente al lío.

Empezamos por el iPhone 5 y su volcado lógico. Recuperamos las llamadas, y encontramos centenares (a S.P.F. realmente le gusta llamar), que cruzamos con los contactos sin encontrar nada reseñable. Tampoco tenemos SMS, pero a cambio tenemos como 12.000 fotos realizadas. S.P.F. es una verdadera yonki de Instagram y si examinamos las últimas fotos podemos ver una el día de autos a las 23.45h junto con R.G.

Su Whatsapp está mucho más animado que el de R.G. Una docena de grupos y cerca de 200 contactos en su agenda dan para mucho… pero no encontramos nada interesante. Dado que tiene un MacBook es casi seguro que tendrá iTunes/iCloud instalados, por lo que nos apuntamos revisarlos y seguimos adelante con el Samsung Galaxy S5.

Autopsy hace su magia y en nada tenemos la imagen abierta ante nosotros: muchísimas llamadas (todas de trabajo), varios SMS de confirmaciones de compra de Renfe, unas cuantas fotos (que dan la impresión de que están hechas para probar la cámara) y multitud de correos electrónicos, todo ellos relacionados con el trabajo. Los datos de geoposicionamiento indican mucho movimiento por Madrid, su empresa y su casa, situándola en su casa en toda la noche de autos.

El análisis de los mensajes de Whatsapp tampoco nos deja mucha más información: un par de grupos (de trabajo), y unos cuantos mensajes con compañeros de proyectos. S.P.F separa a rajatabla su vida personal de su trabajo… menos en lo referido a R.G. según las investigaciones.

Asumimos que las FFCCSSE habrán solicitado el listado de llamadas y el posicionamiento basado en celdas de ambos terminales. Paremos un momento en este aspecto para hacer una aclaración sobre la interceptación de llamadas y la obtención de datos relativos a las llamadas y posicionamiento de un terminal de abonado.

La Constitución Española establece claramente en su artículo 18.3 el derecho al secreto de las comunicaciones, salvo resolución judicial. Asimismo, la Ley de Enjuiciamiento Criminal en sus artículos 579 a 588 especifica las condiciones en las que se puede anular este derecho, al que también se hace referencia en la Ley de conservación de datos relativos a las comunicaciones electrónicas y a las redes públicas de comunicaciones.

Esta ley ha sido criticada por su interferencia con la CEDH (Convención Europea de Derechos Humanos), pero al final la jurisprudencia ha dictaminado que es legal siempre y cuando se cumpla que sea para un delito grave (es decir, con pena de más de cinco años) y que no existan otros medios para obtener dicha información.

[Nota: Se puede hablar largo y tendido de esta conjunción de leyes, y es muy necesario que un buen perito forense se las conozca al dedillo. Tenéis un ensayo excelente al respecto aquí].

El tema de la localización de móviles vía posicionamiento en celdas es también apasionante, pero los chicos de Kriptópolis han hecho un trabajo sensacional explicándolo con pelos y señales, así que pongámonos de nuevo manos a la obra con la imagen del MacBook.

Si lo miramos con detalle observamos que es un MacBook Pro de 13’’ (sin pantalla Retina) así que tiene que tener como SO una 10.7 (Lion para los amigos), que es a priori amigable para un forense.

Montamos la imagen en modo solo lectura en nuestro Linux (habiéndonos asegurado previamente que tenemos las hfsprogs instaladas), y accedemos al fichero de información de la versión del Mac:

/System/Library/CoreServices/SystemVersion.plist

Bajo la etiqueta XML ProductVersion nos encontramos lo que temíamos:

<key>ProductVersion</key>
<string>10.10</string>

10.10 equivale a OS X Yosemite, que no es el SO por defecto que venía con el portátil. La fecha de instalación la obtenemos de la fecha de creación del fichero:

/private/var/db/.AppleSetupDone

Que resulta ser también un par de días antes del día de autos. Una reinstalación es explicable, pero ¿dos? ¿y en el mismo día? Cada vez la cosa huele peor… pero seguimos teniendo que encontrar el cadáver (digitalmente hablando).

Buscamos herramientas para la recuperación de ficheros borrados de un Mac, y encontramos dos: Data Recovery Wizard for Mac y Disk Drill. La segunda solo nos deja visualizar los ficheros que se pueden recuperar (hace falta la versión de pago para ello), pero la primera nos deja recuperar hasta 2Gb de datos.

Probamos ambos programas y el resultado es bastante similar: centenares largos de ficheros, sobre todo temporales de navegación y fotos, muchas fotos (su adicción a Instagram era mayor de lo que creíamos). Esto también nos ofrece un indicio interesante: el MacBook no fue borrado de forma segura. Quizás no se esperaban este nivel de escrutinio, o no sabían cómo borrar un Mac de forma segura…

Revisamos algunos artefactos forenses: historial de navegación, software instalado y correos sin encontrar nada digno de mención (hace dos días que está instalado, no puede tener gran cosa). Por no tener, no tiene ni un backup de iTunes al que podamos hacerle maldades…

La verdad es que queda poco donde rascar, pero luego se nos ocurre una idea loca: S.P.F. tiene un iPhone, un MacBook y es una loca de las fotos. Y seguro, seguro, que no querrá que toooodas esas fotos se pierdan si algo le pasa a su dispositivo. Si las FFCCSSE no han encontrado ningún dispositivo que haga de Time Machine, lo más probable es que tenga una cuenta de iCloud.

iCloud es la copia de seguridad multifunción de Apple para todos sus dispositivos: iPhone, iPad, iMac … si tiene manzanita y es nuevo seguro que puede conectarse a iCloud. El acceso se realiza a través de un usuario y contraseña, que facilita el acceso al panel de control y permite consultar las copias de seguridad y muchas otras opciones.

Como no nos van a dar los datos de acceso a iCloud, tenemos que ser creativos. Romper la contraseña de iCloud es una locura ya que está cifrada en el keychain del SO, y ninguno de los password crackers modernos soportan ese algoritmo. Sin embargo, el funcionamiento de iCloud nos deja un cierto resquicio por donde trabajar.

Cuando un usuario se autentica con iCloud deja unos token de autenticación en el sistema, para que de esa forma el usuario no tenga que introducir su contraseña cada vez que iCloud quiera operar (este token sigue activo hasta que el usuario cierra sesión voluntariamente en iCloud). Si obtenemos ese token podemos hacernos con una copia de Elcomsoft Phone Breaker por un módico precio (799€) que nos permite acceder limpiamente a todo el contenido de iCloud.

Sin embargo, si nos leemos la letra pequeña comprobamos que para recuperar el token nos hace falta la contraseña del keychain, por lo que estamos como empezamos. No podemos recurrir al iPhone porque no tenemos un volcado físico y no tenemos un backup de iTunes desde el que obtener el keychain en claro… por lo que por ahora, estamos bien jodidos.

Solo nos queda una bala en el cargador: S.P.F. es una usuaria. Y los usuarios (además de mentir) son vagos. Muy vagos. Vamos a probar a extraer el hash de su contraseña de usuario, crackearlo y confiar en que sea el mismo. Teniendo acceso a la imagen forense la extracción es instantánea, pero crackear hashes es una tarea que puede complicarse si la contraseña es robusta.

Menos mal que Amazon EC2 está para estas (y otras muchas) cosas. Lanzamos una instancia con GPU (bonitas, preciosas y lozanas Teslas de última generación), montamos hashcat y lo dejamos correteando alegremente mientras le da zapatilla al hash.

Trece horas (y unos 8€) más tarde tenemos la contraseña: “Sa1Man2ta”. ¡Por fin hemos tenido algo de suerte en esta investigación! Estamos con la tarjeta de crédito en la boca para pagar los 799€ de licencia cuando se nos enciende la bombillita: ¿y si S.P.F. ha sido REALMENTE vaga?

Buscamos el nombre de usuario de iCloud de:

/Users/$USERNAME/Library/Application Support/iCloud/Accounts/

Y probamos a iniciar sesión con “Sa1Man2ta”. Suenan coros celestiales en versión heavy metal, y una sonrisa tipo buzón ilumina nuestra cara: Inicio de sesión correcto.

Lo que encontramos dentro de esa cuenta de iCloud, en la próxima entrada…