Shared Preferences y SQLite en Android ¿Seguridad? (II de III)

Tal y como comenté en la primera entrada de esta serie, en ningún momento se debería usar esta información para realizar ninguna acción ilegal, como modificar fechas de expiración de aplicaciones, leer datos privados ni obtener claves de seguridad privadas de terceros. Publico estas entradas sólo con el ánimo de enseñar los problemas de seguridad que nos pueden traer asociados el desarrollar nuestras aplicaciones con un método de almacenamiento de datos determinado y el poco cuidado que ponen ciertos desarrolladores de aplicaciones a la hora de tratar datos tan sensibles como las claves públicas y privadas de nuestro servicio de almacenamiento en la nube “supuestamente” seguro, o el crear un sistema de licenciamiento de aplicaciones basado en almacenar la fecha de expiración en el propio dispositivo en lugar de hacerlo en servidores en la nube del propio desarrollador o con algún método más eficaz, como encriptando de algún modo dichos datos.

Hecha esta aclaración, insisto en que cada uno es responsable de la aplicación que le dé a esta información y que quede constancia de que puede estar incurriendo en acciones ilegales.

Volvemos al tema de la seguridad o inseguridad que obtenemos al guardar según qué datos sensibles de aplicaciones en las Shared Preferences de Android o en bases de datos SQLite.

En esta nueva entrada, vamos a ver como aplicaciones destinadas a ofrecer seguridad por ellas mismas, se vuelven vulnerables por el simple hecho de almacenar datos sensibles de una manera incorrecta.

En concreto vamos a hablar de “WatchGuard Mobile VPN”.

Es una aplicación de la compañía WatchGuard, que nos permite crear túneles VPN seguros entre nuestros dispositivos y los UTM de dicha marca. Hay que comentar que los UTM que ofertan son excelentes en su cometido y aportan una gran seguridad y posibilidad de gestión a las redes empresariales, pero no quita para que sean algo más cuidadosos con el desarrollo de aplicaciones y herramientas de servicio a los clientes.

Viendo que su finalidad en un sentido u otro es aportar seguridad, ¿por qué no almacena los datos de una manera consecuente con su cometido?

Veamos qué pasa cuando accedemos a la base de datos SQLite que utiliza “WatchGuard Mobile VPN”, con Hack App Data (aplicación explicada en la primera entrada de la serie).

imagen1 imagen2 imagen3

Como podemos observar, en la primera pantalla nos aparecen los datos de la aplicación. En la pestaña de Shared Preferences no aparece nada, ya que esta aplicación sólo almacena datos en SQLite. En la tercera pantalla, la de bases de datos, vemos que utiliza una llamada “VpnProfile”, donde se almacenan todos los perfiles de VPN que utiliza la aplicación para conectar a los distintos dispositivos UTM.

Si pulsamos sobre “VpnProfile”, accedemos a la pantalla de tablas de dicha base de datos.

imagen4

Pulsando sobre la tabla “VpnProfile”, accederemos a los registros de los perfiles que hay almacenados en la tabla.

imagen5 imagen6

Como podemos observar en los registros de la base de datos, se almacenan los nombres de perfil, dirección IP de los dispositivos UTM a los que conectar, nombre de grupo de VPN necesario para conectar, así como la contraseña para validarse en dicho grupo.

Si observamos la segunda imagen, también se almacenan los nombres de usuario y password de los clientes en texto plano, así como los ruteos que añade al PC cuando nos conectamos para poder acceder a las redes remotas a través del túnel.

Tratándose de aplicaciones y dispositivos dirigidos a aportar seguridad en nuestras comunicaciones, es un fallo de seguridad bastante importante. Por este motivo siempre recalcamos desde el punto de vista de la seguridad que los datos, siempre que se pueda, hay que almacenarlos cuando menos encriptados.

Hasta la próxima, saludos.

Shared Preferences y SQLite en Android ¿Seguridad? (I de III)

Antes de empezar con estas entradas me gustaría dejar claro que en ningún momento se debería usar esta información para realizar ninguna acción ilegal, como modificar fechas de expiración de aplicaciones, leer datos privados ni obtener claves de seguridad privadas de terceros. Publico estas entradas sólo con el ánimo de enseñar los problemas de seguridad que nos pueden traer asociados el desarrollar nuestras aplicaciones con un método de almacenamiento de datos determinado y el poco cuidado que ponen ciertos desarrolladores de aplicaciones a la hora de tratar datos tan sensibles como las claves públicas y privadas de nuestro servicio de almacenamiento en la nube “supuestamente” seguro, o el crear un sistema de licenciamiento de aplicaciones basado en almacenar la fecha de expiración en el propio dispositivo en lugar de hacerlo en servidores en la nube del propio desarrollador o con algún método más eficaz, como cifrando de algún modo dichos datos.

Hecha esta aclaración, insisto en que cada uno es responsable de la aplicación que le dé a esta información y que quede constancia de que puede estar incurriendo en acciones ilegales.

Siguiendo con las entradas de dicadas a Android, esta vez os voy a hablar de las “Shared Preferences”.

Ya os dejé claro en el primer post sobre Android, que no soy ningún experto en el tema, así que podéis encontrar alguna información que sea incorrecta. Agradeceré cualquier comentario al respecto para hacer la entrada lo más fiable posible.

Cuando desarrollamos una aplicación en Android, tenemos distintas maneras de almacenar la información que nuestra aplicación necesita. Según la guía de desarrolladores de Android, las opciones que tenemos son las siguientes:

  • Shared Preferences: Almacenamiento privado en parejas “clave-valor”.
  • Almacenamiento Interno: Almacenar los datos privados en la memoria del dispositivo.
  • Almacenamiento Externo: Almacenar los datos públicos en el almacenamiento externo.
  • SQLite: Almacenar los datos en una base de datos SQLite privada.
  • Conexión de Red: Almacenar los datos en una web o nube en nuestro propio servidor.

Si utilizamos “Shared Preferences” en nuestra aplicación, las parejas clave-valor serán almacenadas en un archivo XML dentro de nuestro dispositivo, pudiendo elegir al desarrollar la aplicación si el archivo será accesible sólo por nuestra aplicación o puede ser accedido también por otras aplicaciones y compartir los datos.

El problema de seguridad que se nos presenta con éste método es, que siendo “root” del dispositivo, podemos tener acceso a dichos archivos XML de las aplicaciones y poder leer y modificar los datos almacenados en ellos. A simple vista no parece un fallo grave de seguridad, pero si lo analizamos más profundamente nos daremos cuenta de que podemos modificar, por ejemplo, una fecha de expiración de una aplicación que un desarrollador descuidado ha guardado ahí sin cifrar u ofuscar de algún modo, leer los mensajes de WhatsApp almacenados en la base de datos SQLite del dispositivo (sí, eso que todo el mundo pregunta cómo se puede hacer) y acceder a los archivos multimedia guardados en los servidores de WhatsApp (ya que tenemos las rutas URL de cada unos de los archivos enviados y recibidos en dicha base de datos SQLite), así como sacar claves públicas y privadas de Mega, por ejemplo (esas que te permiten descifrar cualquier archivo de Mega que te pertenezca y cifrarlos como si fuesen tuyos) que se quedan almacenadas en el archivo XML en texto plano. ¿Tal vez activar una opción de una aplicación que sólo es accesible desde la versión de pago? Si está almacenada en las Shared Preferences, tal vez sólo hay que sustituir un “false” por un “true” para que esté accesible para nosotros también…

En esta primera entrada sobre “Shared Preferences” nos centraremos en explicar el funcionamiento de una de las muchas aplicaciones que nos permiten acceder a los datos y cómo podemos modificarlos de una manera muy sencilla. La aplicación se llama “Hack App Data” de SteelWorks, disponible gratuitamente desde Play Store.

La necesidad de ser “root” del dispositivo es porque a priori, los archivos están almacenados dentro de las carpetas de sistema, y no son accesibles por exploradores que no tengan permisos de superusuario (otra excusa más para probar a rootear nuestro dispositivo).

Si somos “root”, no hace falta ni siquiera buscar el archivo y exportarlo a un PC, ya que con las citadas aplicaciones podemos acceder desde el propio dispositivo a todos los archivos XML de todas las aplicaciones que tenemos instaladas (tanto aplicaciones de Usuario como aplicaciones de Sistema)  y modificar sus valores directamente.

Una vez instalada y ejecutada dicha aplicación, nos aparece una pantalla donde podemos elegir de qué tipo de aplicaciones queremos mostrar los archivos XML. Podemos escoger entre aplicaciones de usuario o aplicaciones de sistema.

imagen1 imagen2 imagen3

Dentro de las aplicaciones de sistema encontraremos el calendario, la propia Play Store, Gmail, Contactos, Aplicación de Teléfono, Galería… y todas las aplicaciones que vienen integradas en el sistema operativo del teléfono o tableta.

Si optamos por las aplicaciones de usuario, encontraremos todas las aplicaciones que hayamos descargado e instalado que no forman parte del propio sistema operativo.

Seleccionamos una de las aplicaciones pulsando sobre ella y nos aparecerá una nueva pantalla con los datos básicos de la aplicación: nombre, nombre del paquete instalado, tamaño, fecha de instalación…

imagen4 imagen5 imagen6

Seleccionando el botón “Preference” que se encuentra al pie de la pantalla, podremos ver todos los registros que almacena la aplicación en las citadas “Shared Preferences”.

Si seleccionamos el botón “Database” y la aplicación tiene una base de datos SQLite donde almacenar datos, nos aparecerá una pantalla con todas las bases de datos que utiliza.

Seleccionando una base de datos concreta, nos aparecerá una nueva pantalla con las tablas que contiene dicha base de datos, y seleccionando una tabla, nos aparecerán los registro propiamente dichos.

imagen8 imagen9

Comentar que los registros de la base de datos SQLite no son editables desde esta aplicación, pero podemos encontrar muchas gratuitas en el propio Play Store que nos permiten gestionar las bases de datos de este tipo.

Y pasamos a la parte que nos ocupa en esta entrada del blog, seleccionar las “Shared Preferences”.

Desde esta pantalla sí que podremos pulsar sobre una pareja clave-valor y editar su contenido, pudiendo guardarlo directamente en el dispositivo.

imagen7 imagen10

Sólo habría que pulsar sobre el botón “Save” para que los cambios se guardasen en el archivo en cuestión, y que la aplicación en la siguiente ejecución tomase el nuevo valor editado.

¿Y si cambiamos el valor de una pareja clave-valor almacenada que se llama “expiry” y tiene por valor 1397656370 (Epoch Time Linux)? ¿Si cambiamos el primer 1 por un 5 por ejemplo? Podéis probar por vosotros mismos pero probablemente la aplicación en lugar de “expirar” en 2014, expiraría en 2141.

Hasta la próxima, saludos.