Mostrando entradas con la etiqueta Android. Mostrar todas las entradas
Mostrando entradas con la etiqueta Android. Mostrar todas las entradas

En esta segunda parte, se procederá a recuperar un mensaje que ha sido eliminado en la base de datos SQLite de la aplicación WhatsApp y se analizará la información obtenida para determinar cuando se envío el mensaje (timestamp) recuperado.

Estructura de SQLite (II)

Una vez que conocemos el esquema de la base de datos, y como se organiza la información útil (payload data) dentro de las celdas de cada una de las páginas, es conveniente conocer el formato completo del fichero SQLite (file format) para navegar en el fichero de forma adecuada.

Lo primero que se necesita es conocer el tamaño de las páginas y el número total de páginas que contiene la base de datos, esta información se encuentra dentro de la cabecera de la base de datos (database header).

Analizando la base de datos del ejemplo (msgstore.db) y utilizando mi propia herramienta DFSLite (Digital Forensics SQlite Tools) desarrollada para la ocasión, se obtiene que:

ST2Labs 4 - SQLite Database Header Info
Como se observa en la imagen anterior, se tiene que:
  • Page_size = 4096
  • Num_page = 27

La base de datos en el momento del análisis tiene un máximo de 27 páginas, como cada página tiene un tamaño especifico, se puede calcular el Offset de acceso al fichero para cada una de las páginas utilizando la siguiente formula:

Offset (pagina N) = (N -1) * Page_size 

Se debe de tener en cuenta que las páginas se numeran desde 1 hasta N, y que el Offset para la primera página es 0.

Cada página dentro de la base de datos (excepto la primera página) guardan el siguiente formato:
ST2Labs 5 - SQLite Page Format
Las celdas (registros) de la base de datos se rellenan desde el final de la página hacia el inicio, con objeto de permitir que el Cell Pointer Array aumente según se agregan registros a la página. 

Analizando el contenido del "Cell Pointer Array" se obtienen el número de celdas que contiene la página y el offset relativo a la página donde comienzan. Con DFSLite se puede obtener un listado con todos los Cell Pointer Array e información sobre los registros que existen en cada una de las páginas de la base de datos de la siguiente forma:

ST2Labs 6 - SQLite Page Cell Pointer Array Info
ST2labs 7 - SQLite All Cell for Page List

























Esta información es útil para identificar rápidamente que páginas tienen registros (celdas) de información y cuales no. Además de obtener el Offset absoluto y el número total de registros que hay dentro de la base de datos en cada página.

Toda esta información es interesante desde el punto de vista Forense, para centrar el análisis en aquellas páginas que no tengan registros (mayor espacio sin utilizar), en busca de posible información eliminada y que se encuentre almacenada.

Esto es posible, dado que como si de un sistema de ficheros se tratase cuando se elimina información de la base de datos, esta no se "borra" físicamente (no se sobrescribe de forma inmediata) simplemente se elimina el indice de localización de la información en la base de datos, y se queda residente en el fichero hasta que ésta sea sobrescrita posteriormente con otra información.

Por ello, el periodo de tiempo desde que un registro fue eliminado hasta que se analiza de forma forense es crucial para recuperar la mayor cantidad de información, influyendo directamente el nivel de intensidad de uso de la aplicación en ese tiempo con la capacidad de recuperación de información útil.

Hasta aquí la introducción resumida del formato SQLite, se puede profundizar más en el formato consultando la documentación oficial en el siguiente enlace. 

A continuación vamos directos a analizar la estructura de la tabla "Messages" de la aplicación WhatsApp dentro de la base de datos SQLite.

Estructura base datos Whatsapp

Tal y como se comprobó en el primer articulo, con ayuda de la herramienta sqlite_ex, se averigua que la tabla "messages" de WhatsApp se encuentra almacenada en la página 3 de la base de datos SQLite (msgstore.db).


Con ayuda de un editor hexadecimal, abrimos la base de datos y nos dirigimos al Offset = 8192 correspondiente a la página 3 (véase la formula comentada anteriormente para el cálculo). Para localizar rápidamente los registros dentro de la página, me apoyo en la DFSLite con la opción -p 3, para analizar la estructura del CellPointerArray de la página, tal que así:

ST2Labs 9 - Cell Pointer Array Info Page 3

El CellPointer Array se encuentra en el Offset: 8200, se realiza un Decode de "Data" y se obtiene el total de Offset relativos a la página donde se encuentran los registros válidos (existentes) dentro de la base de datos:

Decode Cell Pointer Array Data:

  -  Offsets:               [4048, 3390, 3269, 3166]

Con el Offset relativo a la página 3, se puede calcular el Offset de cada una de los registros válidos de la base de datos (msgstore.db).

por ejemplo: Cell Offset 3166 se corresponde con el Offset absoluto: 11358, se abre la base de datos con un editor hexadecimal y se obtiene:

ST2Labs 10 - Hexa Cell Data Offset 11358
La estructura de un registro (celda) de información de tipo Table, de una base de datos SQLite tiene la siguiente estructura:

ST2Labs 8 - Sqlite Cell File Format
Para calcular el tamaño de la celda, y el tamaño del payload la base de datos SQLite utiliza el tipo VarInt, que consiste en el algoritmo de codificación estático de Huffman de 64 bits, que permite codificar en un máximo de 9 bytes el tamaño de la celda y/o el payload data.

 ** Para este artículo, no se va a explicar como decodificar los tipo de datos VarInt.

Analizando la Información


Un registro (cell) dentro de la página 3 de la base de datos SQLite (msgstore.db) de la aplicación WhatsApp almacenará la información de la siguiente forma:

ST2Labs 11 - WhatsApp Cell Payload Data SQLite Struct


La información se almacena dentro de una "celda" de la base de datos SQLite de forma continua, la imagen 4 representa "payload data", por tanto lo más interesante es saber que después del mensaje "Data" a continuación le sigue el timestamp.

Analizando la información de la imagen 10, se puede observar que se tiene el Key_remote_jid | key_from_me | key_id | status | data | timestamp. Se ha escogido un registro "no borrado" de la base de datos para analizar, de forma que se pueda contrastar la información resultante.

Con ayuda de DFSLite, se puede extraer la información para el registro 11358 de la página 3, donde se resumen de la forma siguiente:

** Page 3     - Cell Data 1/4 Offset 11358

  -  RowID:           8
  -  Size:                101
  -  Header:            32
  -  Data: 
  
20004108270808290500000f0800000008080808000d0501010100000008
0000333436373432353639313540732e77686174736170702e6e65745557
6870734b34507765664330546f646f20656e206f7264656e210151245e46a
8300151245cfd47ffffff

Cada uno de los campos de la base de datos se codifica según lo que en SQLite se conoce como "Serial Type Codes Of The Record Format", como ya podéis imaginar con DFSLite he decodificado la información del PAYLOAD HEADER y se obtiene el tipo de cada uno de los campos de la base de datos y el tamaño, para el caso aquí se analiza, el timestamp es tipo Integer (48bits) ~ 6 bytes.

ST2Labs 12 - DFSLite Decode Cell SQLite Data

Analizando la información con ayuda de un editor hexadecimal:

ST2Labs 13 - Cell Data to Offset 11358
Ya tenemos el timestamp del mensaje de WhatsApp, solo hace falta decodificar el valor hexadecimal convertido a decimal para obtener un valor Fecha y Hora.

Pero esto lo haremos en la ultima parte de mi artículo donde publicaré el código de DFTime que convierte el timestamp de 6 bytes, y comentaré como recuperar mensjes "eliminados" de la base de datos.

#ST2Labs
#GEOSystemSoftware

www.st2labs.com | www.seguridadparatodos.es
Hace poco me he tenido que enfrentar al análisis forense de la aplicación Whatsapp en Android, y la sorpresa es la limitada información que existe al respecto. Whatsapp no tiene una API pública, y no sólo eso, sino que persigue claramente a quién tras aplicar ingeniería inversa publica información al respecto, me estoy refiriendo sobretodo a la información del protocolo interno de la aplicación.

Antecedentes

Independientemente de la información existente, mi reto no era descifrar la base de datos y recuperar los mensajes (sobre esto si se encuentra disponible un amplio abanico de artículos en Internet), sino recuperar mensajes eliminados de la base de datos, tanto si la aplicación ha sido eliminada (desinstalada) como si simplemente se ha eliminado el historial de chat desde el interfaz de la aplicación.

Por tanto, el trabajo es analizar la estructura interna de una base de datos SQLite, con el objetivo de recuperar la información que ha sido eliminada y que una sentencia SQL no es capaz de mostrar.

En este punto es donde empieza mi artículo, analizar el formato de SQLite para recuperar información eliminada.

Estructura de SQLite

Lo principal para analizar una base de datos SQLite internamente es conocer su formato interno, para ello lo mejor es consultar la documentación oficial (SQLite Database File Format) donde se explica como se organiza la información dentro del fichero con extensión .db (SQLite).

Una base de datos SQLite se organiza internamente en páginas, y dentro de cada página se almacenan los registros (filas), que se llaman celdas, correspondientes a la información de las tablas de la base de datos. Cada página tiene asignada una función dentro de la estructura del esquema de la base de datos (sql_master), es decir, una tabla de la base de datos almacena información en las celdas de una página.

De forma resumida, se puede representar el funcionamiento interno de una base de datos SQLite tal y como se puede ver en la siguiente imagen:

ST2Labs 1 - SQLite Format Brief
Para conocer el esquema de la base de datos, se puede ejecutar una sentencia SQL tal que así:

SELECT * FROM sqlite_master;
o bien, he creado mi propia herramienta que facilita la consulta de información de una base de datos SQLite, tal que así:

python sqlite_ex.py msgstore.db
ST2Labs 2 - WhatsApp sql_master (db_schema)

Además la herramienta permite hacer un "dump" de la base de datos, guardar en un archivo el esquema de la base de datos al completo, o mostrar la información de una tabla en particular, por ejemplo, y siguiendo con el hilo del articulo, vamos a consultar la información sobre la tabla "message" que es donde Whatsapp almacena la información de los mensajes que se intercambian.

python sqlite_ex.py -i messages msgstore.db
ST2Labs 3 - WhatsApp Messages Table Info

Volviendo a la imagen 2, se observa que la tabla "messages" de WhatsApp se encuentra almacenada en la página 3 de la base de datos SQLite (msgstore.db) y la imagen 3 nos muestra el "contenido" como será organizado en la celda que se generan dentro de la base de datos en la página 3.

Volveremos más tarde a esta información, que nos resultará útil más adelante cuando empiece a analizar la estructura interna del fichero msgstore.db para recuperar la información eliminada.

Pero esto lo dejo para mi siguiente artículo.

La herramienta que he utilizado en éste artículo la podéis encontrar en mi repositorio oficial (https://github.com/ST2Labs/DFIR) o descargar la versión para windows directamente a continuación:

sqlite_ex.exe

 sha1: 
7IR6FALIEDG6EPAIE6LVMTZY2UFQVEOO (sha1 base 32)

 sha-256: 
6FE6BB8DB06D1A8E17ACD8B79A372821B23260468A92B54EAE229906D32FFACF

 sha-512: 
9D8A9AC6037F5F75367F31E2516D98613E8633C79536B99A76ACAD56865250A7845C8A411F1AB8213353DE7EB67AE3E429AAE063049E9A44B4E5E95444C3500C

Referencias:
[1] SQLlite File Format

#ST2Labs #GEOSystemSoftware
#DFIR
#Forensics



Es inusual escribir en inglés, pero en esta ocasión he preferido hacerlo así para ampliar el público objetivo :


First of all, What do you need to start?


1 . Have USB Driver installed in your system [ I supposed you have Windows]
2 . Enable USB Debbugin Options ( press 7 times in build info into Settings Menu )

3 . Need have Bootloader unlocked, if you don't, please check out this link.


Now you are ready to reborn your old Nexus Smartphone, get rooting o install custom recovery tool.

I would like to get rooting into my Nexus 4, because some security tool need have to access root to works well. And time ago I wrote this post about it "root or not?" (check out this link - in spanish only).

[ Get Root ]

Before start, is interesting what you make a backup to be protected if something go wrong!

1. Need have battery more than 70%
2. Download Wug’s Nexus Root Toolkit v2.0.5.
If you meet with requirements, you can start now:

Steps:
1. Restart your smartphone into Bootloader, you can do this keep hold VOL Down + Power button during start the phone.
2. Run Nexus Root Toolkit, select your model type (in my case Choose OCCAM-MAKO Android 5.0.1 - Build LRX22C)
3. Plug the usb of smartphone into your windows system 
4. Press Root Button with Donwload custom loader and recovery.
5. Wait to software detect your device 





If all goes well, Nexus Root Toolkit will do all for you, fisrt of all install a boot with root files, then restart your smartphone to insert a root file system and install a custom recovery too. All is automatic, when all finish you must have your phone rooted.



Now, I want to reborn my Nexus 4 and I have First of All WIPE all data and formating the smartphone, erase all data include operating system. Then smartphone can't start before I install a nwe operating system. !! Becareful if you formating all data even system ¡¡

[ Restore Nexus 4 ]

You can used Nexus Root Toolkit for restore you Nexus, you have to install a official Google ROM, the process is:

Steps to Restore phone:
1. Restart smartphone with Bootloader,
You must Press Hold VOL down + Power button to obtain access. 
2. Run Nexus Root Toolkit, 
Select Device: Choose OCCAM-MAKO Android 5.0.1 - Build LRX22C  
3. Plug the USB of smartphone into the windows system 
4. Press Restore/Upgrade/Downgrade button (next image)




Software donwload automatically from Internet ROM and install into you mobile, !! It's important choose correct device ¡¡¡ and this tool is only for Google Nexus 4 (Mako).


[ Custom ROM ]

Now that you have rooted your phone and custom recovery , these two requirements, you can install custom ROM.

Install new ROM it's easy, only you can save the custom file rom downloaded into internal smartphone storage and restart into recovery mode, then you have install "zip" and reboot when all it's end.

Example:

Send to ROMManager   Direct Download: cm-11-20141115-SNAPSHOT-M12-mako.zip
md5sum: 926e5115a2ec71fd3a01e1390686f5cd      Short URL: http://get.cm/get/ldZ		224.75 MB

Note: You must enabled again "USB Debbuging options" once you had installed a new ROM, even if new ROM haven't root access, you must do the "root process" again.

I recommend install AFWall+ (Android Firewall based on IPtables) so you can control the network traffic flow in your device and help you to protect you against any authorized connection.


#ST2Labs
#Nexus4
#Android
#Security


Hace ya un tiempo que os hable en mi charla sobre [In]Seguridad en Redes Móviles, en dicha charla os comentaba las debilidades / vulnerabilidades que existen en las redes móviles GSM/3G. 

El año pasado en diciembre de 2014, durante el congreso del Chaos Computer Club, los investigadores de Security ReseachLabs han publicado una vez más las debilidades existentes en las redes móviles actuales, y además, han creado un par de proyectos software libre, el primero para alertar y mostrar la inseguridad / vulnerabilidades de las redes móviles en los operadores actuales, y el segundo, una herramienta orientada a la protección , donde se monitoriza la red móvil para alertar y advertir de ataques en la red de tu operador.


[ Mobile Self-Defense / SnoopsNitch ]

Srlabs ha creado y puesto a disposición de todo el mundo (proyecto OpenSource) una aplicación para móviles Android, llamada snoopsnitch, que permite analizar la seguridad de la red móvil de tu operador de telefonía, y detectar algunos de las amenazas existentes, como estaciones base (BTS) falsa que capturan el IMSI, seguimiento de usuarios (Tracking)  y actualizaciones silenciosas, etc.

Además, se puede utilizar la aplicación SnoopSnitch para colaborar en el proyecto open source que muestra y compara la seguridad que existe entre las redes móviles de los operadores de telefonía móvil, este proyecto es http://gsmmap.org/.





Requisitos

Para poder ejecutar y que funcione la aplicación en el móvil se deben de cumplir los siguientes requisitos:
  • Qualcomm-based Android phone (see device list)
  • Stock Android ROM, version 4.1 or later
    Note: Custom Android ROMs like CyanogenMod may or may not work, depending on the availability of a Qualcomm DIAG kernel driver (DIAG_CHAR).
  • Root privileges on phone
Lista completa de compatibilidad de dispositivos: https://opensource.srlabs.de/projects/snoopsnitch/wiki/DeviceList

GNexus 4 / MakoLG-E960CyanogenMod 11-20141115-SNAPSHOT-M12-mako or special kernel

Para los poseedores de un Nexus 4 se necesita una ROM Cynogen con un Kernel modificado. Esto entra en mi lista de TO-DO!

Incompatible Devices:

The following devices have been found to be incompatible and can not be used with SnoopSnitch:
  • Unsupported. Devices with custom ROM such as CyanogenMod which lacks the Qualcomm DIAG kernel driver (DIAG_CHAR)
  • Unsupported. Every device without Qualcomm chipset
  • Unsupported. Samsung Galaxy S2 & S3
  • Unsupported. Nexus 5 with stock Android
  • Unsupported. Huawei Ascend Y300

Download:
SnoopSnitch is released under the GPL v3 license (cf. source:COPYING). The app is known to built under Linux and OS X, see source:README for build instructions.

[ GSMmap]

 GSM Security Map compares the protection capabilities of mobile networks 

Se observa que en España hay muy pocos usuarios contribuyendo a este proyecto, lo que implica escasos datos para el análisis, sin embargo, en Alemania, existen una gran cantidad de usuarios aportando datos al proyecto.



Con los datos aportados, se analizan y se generan datos sobre la seguridad de las redes de los operadores de telefonía móvil. A continuación una captura de pantalla que se puede consultar en www.gsmmap.org sobre España y Alemania, respecto a la protección que ofrecen las operadoras móviles a ataques de interceptación de la comunicación.




En el caso de España, Vodafone y Movistar son las que más protección en redes 3G ofrecen, para ataques de interceptación de la comunicación. Sin embargo, Orange no sale tan bien parada en el analisis comparativo. No obstante, se debe de analizar el resultado de forma cauta, al verificar que no existen suficientes datos, es decir, hay pocos usuarios contribuyendo a este proyecto en España.

Pero al menos, en mi opinión, es un dato muy interesante y una página WEB a tener en consideración si decides cambiar de operador móvil, un nuevo factor de decisión a incluir,y no solo valorar a la operadora por su tarifa / plan o velocidad de los datos.

Además, observar que solamente existen datos comparativos de redes GSM/3G, dado que el despliegue de la red 4G es muy joven, y dispone de mejores medidas de seguridad.

Aplicación en Android 

https://play.google.com/store/apps/details?id=de.srlabs.gsmmap


[ Transparencias / Slides ]

Puedes consultar las transparencia de la presentación que ofreció Security ResearchLabs en el 31C Security Conference el pasado 30/12/2014.

Slides



 [ Vídeo de la Presentación ]

En el pasado 31C Chaos Computer Club Conference Security Research Labs presento su herramienta SnoopSnitch para demostrar la inseguridad que existe en los protocolos de telefonía móvil. En su charla demuestran lo "barato" que resulta interceptar las comunicaciones GSM/3G utilizando la debilidad del protocolo de señalización SS7.




 [ References ]

https://opensource.srlabs.de/projects/snoopsnitch

http://gsmmap.org/#!/about

https://play.google.com/store/apps/details?id=de.srlabs.snoopsnitch

https://play.google.com/store/apps/details?id=de.srlabs.gsmmap
Las vulnerabilidad en el protocolo GSM/3G no es algo novedoso (véase mi articulo al respecto), todos sabemos que cuando no disponemos de cobertura H+/4G, la estación base y el móvil negocian conectarse mediante 2G/GSM/GPRS para no quedarte sin cobertura.

Uno de los ataques que esta cogiendo popularidad es utilizar falsa estaciones base (fake BTS) para capturar el IMSI de los terminales móviles en el radio de acción en el que actúa. La policía, lo suele utilizar en concentraciones / manifestaciones, y/o para rastrear a determinados usuarios/delincuentes.

Tengo el IMSI, y ¿ahora que?

El IMSI (Identidad Internacional del Abonado a un Móvil), una vez se tiene la identificación del abonado, se puede realizar un ataque de suplantación de identidad, spoofing de SMS, llamar a cargo de la cuenta del abonado, etc.

Por ejemplo, en países como Rusia, China o Brazil, los ciberelincuentes están montando estaciones base (Fake BTS) donde capturar el IMSI para realizar SPAM y/o ataques de Phising mediante mensajes de texto (SMS).

A esto hay que añadir que los "hackers" están aplicando ingeniería inversa a las NSA-Tools, y están liberando aplicaciones como TWILIGHTVEGETABLE conjunto de herramienta capaz de monitorizar (capturar) de forma pasiva la red GSM, o DRIZZLECHAIR son 2TBytes con todas las herramientas necesarias, así como pre-hashed (rainbow tables) para crackear (descifrar) el cifrado A5/1 de GSM. !! Es solo cuestión de tiempo que cualquiera pueda espiar las comunicaciones GSM de tu barrio ¡¡

SOLUCIÓN / PROTECCIÓN

Solo existe una solución "preventiva" sería configurar el móvil para evitar que se conecte a la red GSM (2G), esto tiene la ventaja de proteger en los ataques al protocolo GSM, aunque por contra, te quedarías sin cobertura en algunas zonas / edificios. 

No obstante, deshabilitar la red 2G, protege frente a los ataques de cifrado de GSM, pero recientemente se publico que la red 3G tiene una debilidad que permite capturar el ISMI (en el proceso de formar al móvil en 3G a utilizar 2G), por lo que solamente en 4G podríamos decir que estaríamos completamente protegidos (de momento). Aunque tendríamos que poder deshabilitar la red 2G/3G en el móvil, ya que los atacantes pueden formar mediante la Fake BTS a que el terminal móvil utilice 2G/3G.

Por esta razón, se ha liberado la aplicación para Android AIMSICD (Android IMSI-Catcher-Detector), que detecta y evitar que las estaciones base falsa (fake BTS) en redes GSM/3G capturen el ISMI en terminales móviles con Android.




REFERENCIAS


 ¿Qué es Network Log?

Es una aplicación que se encarga de monitorizar en tiempo-real el registros (logs) de las conexiones de datos generado por el módulo iptables en el dispositivo móvil con Android.

La aplicación organiza la información en tablas y gráficos para que sea sencillo analizar la información disponible.


Iptables: se encuentra disponible en el núcleo (kernel) Linux (también en el kernel de Android)  que permite interceptar y manipular paquetes de red. Dicho módulo permite realizar el manejo de paquetes en diferentes estados del procesamiento, por ejemplo: realizar funciones de cortafuegos (filtrar), registrar el tráfico de la red, o incluso implementar el servicio de traducción de direcciones (NAT).
Además, la aplicación muestra estadísticas del uso de la conexión a Internet, muy útil para controlar el gasto de datos, sobre todo cuando no se dispone de tarifa plana.


Requisitos

Para utilizar la herramienta se necesita acceso "root" al dispositivo. Por lo que es necesario realizar un jailbreak de nuestro sistema Android. 


Donwload:

Puede descargar en Google Play, o acceder al código fuente en : https://github.com/pragma-/networklog.


El pasado 15 de diciembre fue publicado en XDA-Developers el exploit que hace posible obtener acceso "root" en Android, aprovechando una debilidad encontrada en la CPU Exynos4.

En principio para los amantes del "modding / tunning" del sistema operativo Android, esto suele ser una gran noticia, pues se podrá realizar el denominado "rooteo" (obtener acceso root en el sistema) con la simple instalación de una aplicación en el teléfono móvil, rápido y sin complicaciones. 


Por tanto desde el punto de vista del usuario normal, se pregunta:
¿A que viene todo este "jaleo"? Si podemos obtener root en un click!

El "jaleo" es debido a la popularidad de uso del chip Exynos 4, para que os hagáis una idea este chip se encuentra presente en al menos los siguientes dispositivos:

  • Samsung Galaxy S2 GT-I9100
  • Samsung Galaxy S3 GT-I9300
  • Samsung Galaxy S3 LTE GT-I9305
  • Samsung Galaxy Note GT-N7000
  • Samsung Galaxy Note 2 GT-N7100
  • Samsung Galaxy Note 2 LTE GT-N7105
  • AT&T Galaxy Note 2 SGH-I317
  • Verizon Galaxy Note 2 SCH-I605 
  • Samsung Galaxy Tab Plus GT-P6210
  • Samsung Galaxy Note 10.1 GT-N8000, GT-N8010, GT-N8013, GT-N8020
Es decir, que todo aquel que posea un Samsung cuyo modelo se encuentre listado en la lista anterior, tiene un chip Exynos 4 con una vulnerabilidad que permite la ejecución de código arbitrario.

Por tanto ¿Quién te dice que no puede existir una aplicación "falsa" (fake) que utilice esa vulnerabilidad para tomar el control de tu móvil en lugar de obtener sólo el acceso root? Esto significa que el teléfono móvil queda expuesto a multitud de amenazas que podrían materializarse con tan solo instalar una App desde la Play Store.

¿Existe Solución?

El propio autor del exploit, indica que existe un parche, una forma de solucionar este problema, pero que no saber el efecto que esto pueda tener en la ejecución de las aplicaciones y/o servicios de Samsung, esto consistiría simplemente en cambiar los permisos W/R a sólo lectura a un fichero determinado:

A simple patch could be to set permissions to 0660 or 0600 in ueventd.smdk4x12.rc, but I don't know how it would affect samsung applications/services.

Para realizar esto de una forma sencilla acaban de lanzar una aplicación [APK], que explota la vulnerabilidad y "parchea" dicha vulnerabilidad con tan solo instalar. Es decir, primero usa la debilidad dele chip para conseguir el acceso "root" necesario para modificar los permisos del fichero que evita que otras aplicaciones "maliciosas" se aprovechen de ella para tomar el control de tu móvil, sin embargo parece que la "cámara del teléfono" deja de funcionar cuando deshabilitas el exploit [fixed] (proteges el archivo ueventd.smdk4x12.rc contra escritura).

[ROOT EXPLOIT+PATCH][2012.12.17] ExynosAbuse APK v1.10 !
This version allows you to disable the exploit (which may break camera), re-enable the exploit (if you need the camera) and to disable the exploit at boot (before any Android app runs). These options do require root (SuperSU or Superuser) to be installed as well.

Por eso, el autor de la aplicación avisa sobre los posibles efectos de solucionar la vulnerabilidad, y ha introducir algunas funcionalidades que permiten habilitar / des-habilitar el exploit desde la aplicación que ExynosAbuse.

Sin embargo, todavía no hay una actualización por parte del fabricante que solucione dicha vulnerabilidad, de otra forma.

Descargar la aplicación ExynosAbuse APK v.1.20 que soluciona el problema aquí.

V1.10
MD5:1d198a60b90125a7f9fffdc432ead12f
SHA1:778c65022937f4150433ffdcdf011a8fb19dbc25
CRC32:ecdc77be

Más información:


Samuel Espinoza, nos envía la siguiente noticia. a través de editores@seguridadparatodos.es:

COMUNICADO DE PRENSA:

Discretio es una aplicación de telefonía segura, disponible en open source. Su difusión se efectuará 
a lo largo de varias fases beta. Actualmente, como prototipo, la primera versión en fase beta 1 está 
disponible  en  Google  Play,  al  igual  que  en  la  página  www.discretio.com.  La  aplicación  está 
disponible desde ya en 4 idiomas: inglés, portugués, español y francés.

Discretio  es un  producto  evolutivo. Siendo  capaz  de realizar llamadas  en  su  fase beta 1, sus 
funciones irán evolucionando: SMS, mensajes vocales, vídeos, llamadas RTC... Asimismo, Discretio 
funcionará en diversos soportes: PC, Mac, Linux, iPhone, tabletas... El uso en una red privada, 
destinado a empresas de un cierto tamaño, también será posible.

De uso extremandamente fácil, Discretio asocia seguridad y ergonomía a la perfección, tal como lo 
afirma Hervé Baroukh, director de MBDSYS: “Durante la fase de concepción, hemos estado muy 
atentos a otorgar una facilidad de uso en el marco de un producto de seguridad. Luego de haber 
alcanzado este objetivo, ahora vamos a concentrar nuestros esfuerzos en los desarrolladores con el 
fin de constituir una comunidad en torno a este proyecto. Solo una comunidad open source va a 
permitir que se vele por la conservación y una duración de alto nivel de protección.”

Las fases beta tienen por función, poner a prueba la aplicación por la mayor cantidad de personas 
posible, para obtener respuestas de las experiencias con las cuales poder ir mejorando el servicio 
Discretio. Por otra parte, la página Internet y el foro están a disposición, convirtiéndose así en un 
lugar de intercambios para los usuarios y desarrolladores de Discretio.
La fase beta 2 abarcará una versión mejorada con nuevas funciones y dará lugar a la creación de 
una comunidad open source. La comercialización debiera comenzar al final de la fase beta 2.

¿CÓMO FUNCIONA?

En la página Web podrás encontrar la siguiente información, utiliza certificados para generar canales cifrados de comunicación donde enviar vía SIP/RTP la voz cifrada (VoIP).

This is how we proceed to encrypt your calls:
The Discretio client generates a private key and an anonymous certificate (rsa2048bit/sha1) that will be sent out to a web service that will have it authenticated by our CA, after the number has been verified by a token sent by SMS.
The certificate is then used to establish a TLS connection (tlsv1.2, key exchange EDH (p of 2048bits) + RSA signature, aes 256 – mode GCM to produce a symmetric encryption, sha384 hash, no compression) with the server.
After the certificate has been received, it is validated by a complete verification of the signature chain (CA signs the client certificates + CAroot).
Once the connection is established, we use the certificate's fingerprint to authorize (or not) the client to access to the service.
During the establishment of a call, we use the SIP signalization protocol. We use the connection to the server encrypted in aes256/GCM as explained earlier. Both clients use the same Diffie-Hellman (pre-generated, primary factor of 2048bits) to set up a classic DH exchange. The public keys of the two parties are exchanged through SIP/TLS.
As for RTP and RTCP parties, for now we are using libsrtp coupled with the aes128 cryptography algorithm in Counter-Mode + an  “hmac-sha1” truncater at 80bits to authenticate the packets. In the near future we will use AES256-GCM-sha1.
We are looking into using the Elliptic Curve Diffie-Hellman (ECDH) for the TLS and DH  for SRTP.

Vídeo demostrativo:



RESUMEN

A falta de probar la aplicación para comprar su funcionamiento real, se puede decir que con este tipo de aplicaciones aquellos que requieran de mayor seguridad en sus teléfonos Android tendrán una aplicación y un servicio a su disposición.

¿Lo has probado? ¿ Cuéntanos que tal funciona?

Un Saludo.




Designed with by Way2themes | Distributed by Blogspot Themes