Freedly Alternativa a Google Reader

0 comentarios

Imagen de www.redusers.com


Cómo todos sabéis Google Reader cerrará sus puertas el día 1 de Julio, una gran decepción para los que usamos esta aplicación de Google.

El comunicado se hizo oficial a través del blog que la empresa le dedicó al servicio, sin más explicaciones que su uso se vio reducido y que quieren invertir más energías en menos productos. Si bien no se aclara en este artículo, habría también una intención de que los usuarios de Reader se alimenten de noticias a través de Google+, a pesar de sus limitaciones en ese sentido.

¿Alternativas? Para empezar el propio Google nos recomienda acudir a Google TakeOut para exportar toda la información de reader y llevarla a otro cliente RSS (en formato XML). Y luego productos como Feedly, que se presenta como extensión para Google Chrome, además de como aplicación para iOS y Android.

Personalmente he probado Freedly (me la ha recomendado un compañero) y me ha sorprendido la facilidad de su uso y la integración completa con nuestra cuenta de Google Reader, y además gratis. También he de comentar que dispone de aplicaciones para iOS y Android en sus respectivas tiendas.

Por ponerle una pega, puedo decir que para empezar a usar Freedly (y a los que tenemos cuenta de Google Reader) es que nos solicita acceso para acceder con nuestra cuenta de Google).

Yo ya he empezado a utilizarlo, y tu??

Things Up!



Análisis Forense en Android (Parte II)

2 comentarios
En la entrada anterior comenté la posibilidad de obtener datos del terminal sin ser root, se me olvidó comentar que es aconsejable tener el terminal en modo avión (aunque en muchos casos es necesario que esté rooteado, sobre todo si tiene patrón de acceso, clave, etc.). En en siguiente ejemplo que vamos a ver voy a usar el comando anteriormente mencionado:


#adb bugreport > bugreportAndroid.txt
#wc -l bugreportAndroid.txt
61497 bugreportAndroid.txt

Salen unas cuantas líneas que revisar, no?? :D


Aqui es importante, o cuanto menos aconsejable, que el terminal esté en modo avión y/o aislado de la red como mencioné en el post anterior, de lo contrario la ejecución del comando nunca terminará, dado que el terminal constantemente está pidiendo conexiones a la red, y lo tendréis que cortar, lo que ello conllevaría que, posiblemente, el report del comando esté incompleto.

Vayamos al tema!

Ya tenemos el fichero en cuestión, vamos a ver qué nos ofrece.

Nada más abrir el fichero veremos algo similar a:



========================================================
== dumpstate: 2013-03-13 16:14:56
========================================================

Build: cm_galaxysmtd-userdebug 4.2.2 JDQ39 eng..20130303.223331 test-keys
Build fingerprint: 'samsung/GT-I9000/GT-I9000:2.3.5/GINGERBREAD/XXJVT:user/release-keys'
Network: movistar
Kernel: Linux version 3.0.66-g6c5dade (xxxxxxxxxx@cyanogenmod)
Command line: console=ttySAC2,115200 loglevel=4 androidboot.serialno=XXXXXXXXXXXXXX bootmode=0

------ UPTIME (uptime) ------
up time: 3 days, 01:19:28, idle time: 1 days, 00:31:41, sleep time: 1 days, 19:24:50
[uptime: 0.1s elapsed]

Vamos a paranos un segundo en revisar estas líneas, podemos ver que el terminal es un Samsung GT-I9000, con la versión de Android GingerBread, Kernel XXJVT, Kernel Version 3.0.66, con cynanogenmod (rom de cynanogen ), operador Movistar, número de serie del terminal y el tiempo que lleva encendido. No está mal nada más abrir el fichero, no?

Voy a saltarme unos cuantos pasos y voy a ir al grano directamente.

Sabemos que el terminal es Android, por consiguiente el propietario del mismo ha de disponer de cuenta en goggle (ya sabés [usuario]@gmail.com) para que el terminal sea operativo al 100%. Pues al grano, realizamos una búsqueda en el fichero y buscamos el patrón: DUMP OF SERVICE account

Al realizar esta búsqueda encontraremos rápidamente el volcado de las cuentas del terminal, y podremos ver algo similar a lo siguiente:


DUMP OF SERVICE account:
User UserInfo{0:Jesus D.:13}:
  Accounts: 6
    Account {name=[usuario]@gmail.com, type=com.google}
    Account {name=[telephone_number], type=com.whatsapp}
    Account {name=[usuario], type=com.twitter.android.auth.login}
    Account {name=[usuario]@gmail.com, type=com.linkedin.android}
 


Pues no está nada mal, no? Básicamente y a un sólo click obtenemos el número de teléfono (eso si, por que el usuario tenía WhatsApp, y quién no??), la cuenta de correo, su cuenta de twitter, linkedin

Ahora bien, otro de los datos interesantes que podemos obtener es la última localización conocida del terminal, realizaremos los mismos pasos anterior, pero ahora el patrón de búsqueda será: DUMP OF SERVICE location

Hemos de encontrar algo así:


Last Known Locations:
    passive: Location[network [coordenada],[coordenada] [....]

Ahora sólo nos quedará ir a google maps y en el cuadro de búsqueda introducir los numeritos obtenidos, eso si IMPORTANTE tenéis que sustituir la coma por puntos, quedaría algo así (coordenadas inventadas) plasmado en el mapa.


Se pueden sacar muchas más cosas interesantes, pero no os lo voy a decir todo no?? Así que a estudiar :D jejejejej

Nos vemos en la siguiente entrada.

Si te ha gustado comparte!

Things Up!

Análisis Forense en Android (Parte I)

0 comentarios
Llevo un tiempo queriendo hacer una mini-guía de cómo realizar un análisis forense a un terminal Android, al menos los puntos básicos, y hoy me he decidido a empezar :D (Nunca es tarde, no).

Como publicaba, a groso modo, en una entrada anterior , donde se describía el proceso de análisis forense, esa parte me la voy a saltar. No obstante publicaré con detalle todo el proceso de análisis forense.

Lo primer que hay que tener en cuenta, cuando nos encontramos en un análisis de un terminal Android es aislarlo de la red, vamos, cortarle toda comunicación con cualquier tipo de red. Lo idea sería disponer de una Jaula de Farady, y qué es esto os preguntaréis, pues básicamente un habitáculo que aísla el terminal de campos electromagnéticos. Por qué hacemos esto? Fácil, queremos conservar la información del teléfono tal cual está en el momento que se nos hace entrega. Lo ideal sería ponerlo en "Modo Avión" pero si tiene patrón de bloqueo, pin o cualquier otro patrón de acceso nos sería, prácticamente, imposible. Eso si, desde aquí es donde tenemos que empezar a documentar nuestra intervención.

Volviendo a la Jaula de Faraday, si no podemos poner el terminal en Modo Avión y tampoco disponemos de una Jaula de Faraday (lógico ya que son caras) yo os recomiendo que envolváis el terminal con Papel Albal, si si, como suena y leéis, Papel de Aluminio, nos hará el mismo efecto que una Jaula de Farady :) (qué cosas verdad :D), con esto tendremos el terminal aislado y podemos empezar a trabajar. (Probad a llamaros, dará que el terminal está apagado). NO le conectéis el cable y luego lo envolváis, ya que el mismo cable hará de antena, así que toca esperar hasta que podamos aislarlo completamente o activar el modo avión.


Por regla general, y desde la versión 2.2 de Android, Froyo, el modo Depuración USB viene activado al conectar el terminal, si esto no fuera así o estuviera desactivado poco podremos hacer, se podría intentar otra cosilla pero vamos a dar por echo de que está activado, de esta forma podríamos empezar con el análisis.

Creo que no es necesario mencionar que necesitamos el SDK de Android, pero por si acaso lo comento, es requisito casi indispensable, por no decir que Imprescindible, así que si no lo tenéis ya podéis descargarlo desde aquí.

Hasta ahora ya tenemos el terminal aislado y con el cable conectado, nos queda conectarlo a nuestro equipo, donde tendremos el SDK de Android y ponernos manos a la obra.

Lo primero que haremos es comprobar que tenemos acceso al terminal, os recomiendo familiarizados con la herramienta ADB (Android Debug Bridge)que incluye el propio SDK.

Una vez conectado el terminal, lo primero que haremos es verificar si está disponible para conectarlo por ADB:


Pues ya sabemos que el terminal tiene el modo depuración activado, vamos a ver si está rooteado o no:


Pues parece ser que no, nos tocará rootearlo (lo veremos en el siguiente post), pero de momento hay una serie de datos que podemos obtener sin ser root.

De todos es bien sabido que Android trabaja con un Kernel de Linux, bien, sabemos que el kernel es la capa más baja del sistema operativo y la cual provee acceso al hardware del dispositivo. Así que tenemos la posibilidad de consultarlo, al igual que en Linux, mediante el comando dmseg.  

¿Qué información podemos obtener?
Básicamente lo que podemos obtener, al ejecutar el comando, es un detalle a bajo nivel de la actividad del dispositivo, sellos de tiempo (arranque, apagado, etc.), e incluso tenemos la posibilidad de volcar el resultado a nuestro equipo para realizar un análisis más detallado:

#adb dmesg >dmesg.log

Android tiene varias técnicas de depuración adicionales disponibles. Otra aplicación interesante es el comando LOGCAT  que nos devuelve una lista permanentemente actualizada de los mensajes del sistema. Un análisis rápido de log devuelto nos puede proporcionar:

-          Datos sobre Longitud y Latitud del Teléfono
-          Información Fecha/Hora
-          Detalles de Aplicaciones

El registro es muy detallado. Es interesante conocer que cada mensaje del registro comienza con un indicador, siendo estos:

-          V: verbose
-          D: debug
-          I: information
-          W: warning
-          E: error
-          F: fatal
-          S: silent

Además, con logcat podemos obtener información detallada de la “radio” del dispositivo mediante el comando:

#adb logcat –b radio

Aunque el detalle del comando es bastante detallado, la exploración de esos registros nos puede proporcionar información muy interesante en nuestro análisis (la cual deberemos documentar), tales como:
-          Hora de los eventos
-         AT commands (radio) usados por el módem interno del terminal para establecer comunicaciones
-          Receptor, tamaño, hora y codificación de los mensajes de texto SMS
-          Ip del dispositivo e información de su localización
-          Información del proveedor de la red WiFi

Podemos decir que una de las características principales de logcat es la visualización de eventos:

#adb logcat –b events

Otra de las herramientas interesantes en nuestro análisis, es dumpsys

Dumpsys  nos ofrece información de los servicios, memoria, y otros detalles del sistema que nos puede proporcionar gran información. Alguna de la información interesante que podemos encontrar es:
-          Servicios actualmente en ejecución
-          Volcados de los servicios
-          Etc.
No sólo podemos obtener los programas utilizados, sino que nos puede revelar, en muchas ocasiones, las cuentas del usuario del teléfono (gmail, Exchange, facebook, twitter, …)

Normalmente todos los códigos de tiempo que podemos obtener se encuentra en milisegundos.

El último comando, pero no menos interesante es bugreport el cual combina todos los anteriores:

#adb bugreport > bugreport.log
#wc –l bugreport.log
42575 bugreport.log

Si te ha gustado comparte, no cuesta nada :)
Nos vemos en la siguiente entrada!!

Things Up!!

La Informática o Análisis Forense

0 comentarios
He decidido escribir acerca de este tema ya que es algo que me apasiona desde hace algún tiempo, y quizás ayude a alguien a entender mejor el concepto.

El cómputo Forense, también llamado Informática Forense, computación forense, análisis forense digital, examinación forense digital o Forensics es la aplicación de técnicas científicas y analíticas especializadas en la infraestructura tecnológica que permiten identificar, preservar, analizar y presentar datos que sean válidos dentro de un proceso legal.

Dicho esto, podemos entender que esta disciplina hace uso NO sólo de tecnología (software) para poder mantener la integridad de los datos y el proceso de los mismos, sino que también requiere de una especialización y conocimientos avanzados en materia de informática y sistemas para poder detectar dentro de cualquier dispositivo electrónico (PC, Smartphone, ...) lo que ha sucedido.


Como apunte a esto podemos decir que se reconoce a Dan Farmer y Wietse Venema como los pioneros de la Informática Forense y fueron los creadores del Coroner's ToolKit. Aunque, a día de hoy, Brian Carrier es probablemente uno de los mayores expertos en el tema y autor de herramientas tan conocidas como The Sleuth Kit y Autopsy Forensics Browser incluidas en muchas distros forenses.

Ya sabemos que, la informática o análisis forense, permite la solución de conflictos tecnológicos relacionados con seguridad informática y la protección de datos y, gracias a ella,  las empresas pueden obtener una respuesta a un problema de privacidad, competencia desleal, fraude, robo de información confidencial y/o espionaje industrial obtenidos mediante uso indebido de las tecnologías de la información.

Creo, que no existe un estándar para todo esto, pero algunos proyectos pioneros, como el C4PDF (Código de Prácticas para Digital Forensics) el Open Source Computer Forensics Manual (seguro que me dejo muchos otros) nos proporcionan una base del análisis forense actual.

De todos es sabido que la finalidad de una Análisis Forense es, bien para anticipar un posible problema (bien realizando Auditorías de Pen Testing) u encontrar evidencias de infracciones ya producidas. Por lo tanto, todo el procedimiento de análisis debe hacerse siguiendo unas pautas legales para no vulnerar y/o modificar en ningún momento el origen de las pruebas y mucho menos vulnerar el derecho de un tercero.




Es muy importante mencionar que la informatica forense no tiene parte preventiva, es decir, la informatica forense no se encarga de prevenir delitos, para ello que encarga la seguridad informatica, es importante tener claro el marco de actuación entre la informatica forense, la seguridad informatica y la auditoria informatica.


Para realizar un adecuado análisis forense es necesario un equipo multidisciplinar que incluya profesionales expertos en derecho de las TI y expertos técnicos en Metodología Forense. Esto es así porque se trata de garantizar el cumplimiento, tanto de los requerimientos jurídicos como los requerimientos técnicos derivados de la metodología forense.

Os pongo un ejemplo de la metodología forense utilizada por el departamento de Justicia de los EEUU.



A fin de cuentas podemos decir que:


  • Las evidencias digitales deben ser tomadas de forma binaria
  • Debe garantizarse que las pruebas NO se puedan manipular mediante la firma HASH (por eso se recomiendan tres copias)
  • Se recomienda, por seguridad, una firma SHA-1 frente a MD5 (Ya que todos sabemos que admite colisiones)

Tocante a las consideraciones Legales en España he de decir que actualmente no existe una ley específica sobre el CiberTerrorismo o la Ciencia Forense, sino que la legislación española está basada en la interpretación de:
  • Código Penal
  • Ley de Enjuiciamiento Civil.
  • Ley de Servicios para la Sociedad de la Información y Comercio Electrónico.
  • LOPD
  • Reglamento de medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal.
  • Ley General de Telecomunicaciones
  • Ley de Propiedad Intelectual
  • Ley de Firma Electrónica
Sería bueno disponer de un organismo regulador al respecto, ya que cada caso es totalmente distinto.

Things Up!!

Android: Saltándonos el patrón de bloqueo

0 comentarios
La seguridad en los dispositivos móviles es algo de vital importancia hoy en día, tomando en cuenta que ya no es como hace muchos años donde lo más que podían robarnos eran los números de nuestros contactos y la información en nuestros mensajes de texto. 
Hoy en día, y con los smartphones, solemos guardar infinidad de fotografías, realizamos conexiones con nuestras entidades bancarias, etc. Por eso es algo que no debemos descuidar.

Hace algún tiempo los chicos de XDA developer encontraron una manera de "saltarse" o romper el patrón de bloqueo de los terminales Android, así que como primera entrada del blog he decidido publicarla.

(imagen de movilzona.es)

Supongamos que nos "encontramos" un terminal Android y tiene el patrón de desbloqueo. La forma de "saltarnos" el patrón es la siguiente (damos por echo que se tienen que tener nociones básicas sobre el ADB de Android y que el terminal tiene que estar rooteado). Disponemos de dos métodos:

Primer método

En consola y a través de ADB, luego de conectado el dispositivo, se deben introducir los siguientes comandos:
 adb shell
cd /data/data/com.android.providers.settings/databases
sqlite3 settings.db
update system set value=0 where name='lock_pattern_autolock';
update system set value=0 where name='lockscreen.lockedoutpermanently';
.quit
Segundo método

Aún más fácil que el anterior, pero también a través de ADB, solamente requiere ejecutar la siguiente orden:

 adb shell rm /data/system/gesture.key

una vez realizado cualquiera de los dos métodos no necesariamente desaparecerá el patrón de bloqueo al encender la pantalla del dispositivo, si no que podremos ingresar cualquier patrón aleatorio y se desbloqueará el terminal
Un fallo muy importante en la seguridad de Android, ya que muchos contamos con este patrón para desbloquear el terminal.
En fin, things up!
Saludos
Copyright © C43S4RS