Nueva herramienta: GmtCheck. ¿De dónde viene esta app de Android o applet?

ElevenPaths    10 febrero, 2014


Existen millones de applets maliciosos (ficheros JAR)
y apps de Android (ficheros APK) ahí fuera. ¿De dónde vienen? ¿De qué país? ¿Al menos, cuál es
su zona horaria? En un estudio forense, puede ser relevante conocer (o al menos establecer indicios) si provienen de Rusia, Brasil,
China, la India o Estados Unidos. Veamos cómo.


Los ficheros dentro de los ZIP

Los APK (apps de Android) y
los applets (y programas Java) vienen todos del mismo formato: son un fichero
ZIP. Esto quiere decir que comparten buena parte de las especificaciones PKzip.
A la hora de crear un fichero ZIP, el atributo «fecha» de modificación de cada
fichero se almacena dentro del ZIP. Se puede comprobar simplemente abriendo un
fichero con cualquier herramienta.
 
La forma en la que se almacena este
dato es curiosa, y hablaremos de ella en alguna otra entrada. La parte
interesante es que el atributo «fecha y hora de modificación» con el que se almacenan
es el mismo que el del sistema en el que se han compilado. También, que hay
ficheros que se crean justo cuando se compila el programa, como el manifiesto
(.mf). Pero, no se da ningún «offset» a esa hora, así que este dato
por sí mismo no permite saber si el APK o el JAR está creado en un país concreto. Un
fichero dentro del ZIP con fecha de modificación a las 23:45 no significa nada por sí solo. ¿Las
23:45 de qué país?
Fechas de modificación de los ficheros dentro de un APK


Ficheros firmados y certificados

Algunos applets se firman, de forma
que pueden escapar de la sandbox de Java y atacar a los usuarios. Los APK casi siempre están firmados, porque Google Play y Android dicen que así debe ser para usarlo en su plataforma. Cuando
están firmados, se añade un certificado dentro de los ficheros ZIP. Este
certificado está en una estructura PKCS7, que es un fichero con extensión (entre
otras) RSA o DSA en el directorio META-INF. Los certificados puede que estén
autofirmados. Esto es gratis y los atacantes no tienen que demostrar a nadie
quiénes son en realidad.
Atacantes y certificados
Fecha de creación del certificado… «Válido desde…»
Los atacantes odian los certificados
firmados por CAs, pero les encantan (y tienen que hacerlo) los certificados
autofirmados. Son gratis y desechables. Pueden crear un certificado autofirmado
ad-hoc para una app y nunca usarlo más. Eclipse y otras plataformas de desarrollo ayuda en esta tarea de crear expresamente certificados a la hora de compilar ficheros apk, como último paso antes
de enviarlo a Google Play.

Los certificados se almacenan dentro
de los APK cuando se crean. Y aquí está el truco. Su hora de creación se almacena sin «zona horaria, o sea, en UTC. En concreto en formato YYMMDDHHMMSSZ. La Z corresponde a «hora zulú», que es UTC o a
efectos prácticos,, casi igual que GMT+0. time zone.
Vista en formato ASN.1 de la fecha de un certificado
Como curiosidad, si un certificado
contiene una fecha más allá de 2049, se usa un formato llamado
«generalizado», que es fundamentalmente el mismo pero incluye la
especificación completa del año con cuatro cifras. YYYYMMDDHHMMSSZ.

Poniéndolo todo junto

Así que por un lado tenemos la fecha
de sistema del creador, y la hora UTC, que no es más que GMT+0. Solo tenemos que asumir que el
certificado y los ficheros son creados justo en el mismo momento para hacer las
cuentas y calcular el «offset» de la zona horaria.

Si un fichero manifest o de firmas
(que son los últimos creados en la compilación de un JAR o APK) contiene la
fecha de sistema 16:00, 1 de enero de 2014, y la hora UTC del certificado pone
que fue creado a las 15:00 del 1 de enero de 2014, si asumimos que se crearon
en el mismo momento, podríamos decir (a menos que el atacante haya modificado su
hora de sistema) que el atacante vive en una zona horaria GMT+1.
Hora UTC – Ficheros ZIP… en su diferencia está el offset y, por tanto, la zona horaria (fuente del mapa: timeanddate.com)
La herramienta que hace el cálculo

Hemos creado una herramienta que
realiza el cálculo. Lee un fichero JAR o APK y, si está firmado:
  • Intentará
    extraer la hora de creación (UTC) de un certificado.
  • Intentará
    leer la hora de modificación del último fichero creado en la compilación (normalmente el
    fichero .sf en el directorio meta-inf).
  • Hará las cuentas y dirá en qué zona
    horaria vive el desarrollador,     asumiendo que la creación del certificado y la
    compilación han ocurrido en el mismo momento (minuto arriba, minuto abajo) y que el desarrollador no ha modificado su hora de sistema.
Estos son algunos ejemplos reales:

Una app fraudulenta desde España

Malware desde E.E.U.U

Una aplicación falsa desde Hong Kong

Este APK es de una aplicación india falsa. Teen Patti poker

La herramienta está disponible en Python y compilada en C#. Ambas pueden ser descargadas desde este enlace: http://elevenpaths.com/downloads/gmtcheck.zip


Invitamos al uso de la herramienta.

Sergio de los Santos
ssantos@11paths.com

Te puede interesar

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *