jueves, 14 de agosto de 2014

Crypt4you – Aprende criptografía y seguridad informática de otra forma y GRATIS

Crypt4you es un nuevo proyecto de Cryptored (Creadores también de la IntyPedia – Enciclopedia visual de la Seguridad Informática) que pretende con un nuevo formato de enseñanza ayudar a la difusión masiva en temas de Criptográfica y seguridad informática en general.

Crypt4you Crypt4you   Aprende criptografía y seguridad informática de otra forma y GRATIS

El proyecto nació en marzo de 2012 y tenia el post en el tintero, incluso Jorge Ramió me mandó un correo sobre el proyecto para ayudar en su difusión, pero con todo el tema del ACK Security Conference y los proyectos que tenia pendientes, solo hasta ahora puedo dedicarle un poco de tiempo a escribir sobre esta gran iniciativa de la Red Temática de Criptografía y Seguridad de la Información Criptored.
La iniciativa Crypt4you ofrece una lección nueva cada 15 días, las cuales serán generadas por investigadores y profesores miembros de Criptored y tiene como meta convertirse en el Aula Virtual de referencia de seguridad de la información de habla hispana con miras capacitar gratuitamente muchos profesionales en Latinoamérica, les dejo el vídeo de presentación del proyecto realizado por el Dr. Jorge Ramió:
Hasta el momento se han generado las siguientes lecciones, con un excelente material audiovisual, escrito y practico.

 de RSA

Curso de privacidad y protección

Computación y Criptografía Cuántica


martes, 12 de agosto de 2014

Ideas para hacer un Proyecto de Fin de Carrera o Fin de Máster en el área de Seguridad Informática y/o Hacking

Hay una serie de preguntas que suelen hacerse aquí reiteradamente. La lista de ellas que aparecen con bastante regularidad crece poco a poco, así que cuando llega una nueva demasiadas veces creo que lo mejor es escribir un post sobre ello. Algunas de las preguntas que más veces me llegan son las de "¿Cómo ser hacker o cómo aprender hacking?", "¿Cómo se puede espiar el WhatsApp?", "¿Ayúdame a hackear el Facebook o WhatsApp de mi novi@?", "¿Qué máster de seguridad hacer?", "¿Qué libros me hay que leer para aprender seguridad informática?", "¿Se debe ir a la Universidad para trabajar en Seguridad?" o "¿Qué lenguaje de programación aprender?" - ésta última no la he contestado nunca -. No todas ellas las tengo contestadas yo, y alguna habría que actualizarla, pero más o menos buscando en el blog hay mucha información de ellas.


Figura 1: Be a hacker como el Inspector Gadjet

Una de las que más ha llegado en los últimos tiempos ha sido de estudiantes de Universidad o Másters que querían alguna idea de trabajos en seguridad para presentar como Proyecto de Fin de Carrera o de Proyecto de Fin de Máster. Siempre se intenta dar algunas ideas que tengan que ver con cosas que tengan que ver con las cosas que a mí me gustan o yo he estado involucrado, que es de lo que sé. 

Hoy, por si alguno está falto de ideas voy a dejar 10 posibles temas para proyectos que tienen que ver con seguridad y cosas que hemos estado haciendo, pero que por falta de tiempo, o por priorizar otras cosas no hemos podido atacar y que tienen que ver con Latch, con los Metadatos, con Seguridad Web y alguna otra cosa.

1) Integración de Latch en frameworks de Internet con Segundo Factor de Autenticación
Latch es una tecnología que se puede utilizar como Segundo Factor de Autenticación en frameworks de Internet. Nosotros desde Eleven Paths lo hemos integrado en un montón de ellos, como PrestaShop, WordPress, PHPMyAdmin, PHPBB, Open X-Change, OpenLDAP o RoundCube, pero aún quedan un montón de ellos que no hemos podido integrar. Todos esos plugins son Open Source, así que puedes ver el código fuente de cada uno de ellos y entender cómo se integra un 2FA en cada uno de ellos. Además, para que sea mucho más fácil de entender cómo se hace, hemos escrito un artículo en el que se detallan todos los cambios que se hacen por debajo a WordPress cuando se integra Latch
Si quieres integrar Latch en phpLDAPAdmin, en Horde, en cPanelSQL Web Data Administrator, o en cualquier otro framework, será un proyecto que te hará aprender, un bonito proyecto Open Source actual y contarás con nuestra ayuda para solventar cualquier dificultad.
2) Evaluación de fugas de datos en sitios web por medio de documentos públicos
Este es un proyecto de investigación sencillo, que nosotros ya hemos hecho con empresas del IBEX 35 y en las webs de los líderes en DLP. La idea es evaluar qué cantidad de fugas de datos se producen en sitios en los que no debieran producirse. Para ello, elegir un sector de estudio como banca, administraciones públicas de tu país, empresas de una determinada industria, etcétera, podrían arrojar datos significativos. Los riesgos de los metadatos son muchos, y yo tengo ya más de treinta ejemplos de por qué los metadatos hay que cuidarlos.
3) Detector de casas vacías
Una de las cosas que más me sorprende es que se pueda hacer es ver a través de muros utilizando tecnología WiFi. Hemos visto que incluso se puede monitorizar los latidos y la respiración de un bebé. ¿Se podría hacer un sistema que detectara si una casa está vacía utilizando un escáner WiFi? Yo creo que sí, y sería importante poder alertar del riesgo.
4) Un configurador de redes WiFi usando impulsos en el magnetómetro
Hace no demasiado vimos que por medio de un sistema sería posible enviar mensajes con bajas frecuencias usando impulsos en el magentómetro de un terminal móvil. ¿Qué tal hacer una app en Android que sirviera para configurar la WiFi de un espacio? El usuario solo debería dejar su terminal unos segundos y la WiFi quedaría correctamente configurada.
5) Configurador remoto de apertura y cierre de puertos en un firewall con Latch
Usar Latch permite muchos esquemas distintos, como Verificación en 4 ojos, Control Parental, Supervisión o como hicieron en HackPlayers, Activación con 2 llaves. ¿Qué tal hacer un daemon que monitorice cada 5 minutos si los puertos de un firewall deben estar abiertos o cerrados y configurar tu iptables? Así, el usuario desde su app puede abrir o cerrar en todo momento qué puertos quiere tener activos y cuáles no.
6) Búsqueda de backups automatizado en Apache con Mod_negotiation
El módulo de mod_negotiation de Apache muestra archivos con distintas extensiones cuando se pide un nombre de fichero que no se encuentra. Este truco se puede utilizar para buscar backups en los servidores webFOCA busca estos bugs automáticamente y sería interesante hacer un plugin para FOCA - o una herramienta stand-alone - que una vez descubierto que el servidor Apache tiene mod_negotiation activado busque todos los archivos de la web para después buscar todos los ficheros sin poner la extensión y descubrir ficheros "copia" de los originales.
7) Un reconocedor de cerraduras, candados o de llaves para lockpicking usando Google Glass
Las Google Glass se pueden utilizar para mil cosas de hackingcomo robar un passcode, pero también podrían usarse para lockpicking. Por ejemplo, podrían reconocer una llave de una cerradura y saber marca, modelo y los códigos si se ven con la llave, o reconocer una cerradura o candado por fuera y recomendar la forma de apertura correspondiente. Una bonita app que llevar en las gafas.
8) Una dock station integrada con Latch
En el trabajo, muchas veces se dejan los equipos en dock station para que se cargue la computadora portátil al mismo tiempo que se pueden utilizar periféricos. ¿Qué tal integrar un sistema de verificación de Latch para desconectar el equipo de la docky? Ya tienes un ejemplo del mundo físico en el que Latch controla el cerrojo de una puerta.
9) Un app que muestre el historial de uso de la webcam
Cada vez que se enciende una webcam queda un registro de actividad. Saber a qué horas estaba encendida y a qué horas estaba apagada puede ser de utilidad para todo el mundo y especialmente para padres que pueden detectar si un joven está siendo espiado o está haciendo video conferencia con alguien. Hacer una aplicación que cualquiera pueda ejecutar en un WindowsLinux u OS X y muestre el historial de uso de la webcam sería de utilidad.
10) Robo de sesiones Google con Google Authenticator
Google Authenticator es un segundo factor de autenticación, pero al final el código de autenticación hay que ponerlo en el mismo canal. Como el código de autenticación tiene un periodo de vida, en un ataque de man in the middle en el que se robe el usuario y la contraseña - por ejemplo haciendo un Bridging HTTP(IPv6)-HTTPS(IPv4) - y después robar el código de Google Authenticator para tal vez conseguir dos sesiones autenticadas con el mismo código.
Son solo ideas que rondan por mi cabeza y que seguramente propondré como trabajos de Fin de Máster para el curso que viene en el Máster de Seguridad de la UEM. Si alguno de vosotros se anima a hacerlas y me lo cuenta, sería genial. Si alguna de ellas os estimulan para hacer otra cosa genial. Según se vayan haciendo, iré actualizando las ideas, para que siempre haya al menos 10 ideas frescas sin hacer.


domingo, 10 de agosto de 2014

Vulnerabilidades en Android que pueden arruinarte (CVE-2013-6272 & com.android.phone)

Se han anunciado dos nuevas vulnerabilidades en sistemas Android (anteriores a la versión 4.4.4) que podrían permitir a una aplicación maliciosa realizar llamadas a números de tarificación especial sin que
el usuario se percate de ello y aún sin permisos para ello.
Las dos vulnerabilidades, muy similares entre sí, han sido anunciadas por Curesec.  El primero de los problemas, con CVE-2013-6272, aparece en Android 4.1.1 Jelly Bean y se presenta en todas las versiones hasta Android 4.4.2 KitKat.



Reside en com.android.phone y todo parece indicar que se ha corregido en la última versión 4.4.4.
Por otra parte, una segunda vulnerabilidad (sin CVE asignado todavía) en com.android.contacts solo está presente en las versiones Android 2.3.3 y 2.3.6. Ambas vulnerabilidades son explotables de la misma forma con idénticos resultados.

Versiones afectadas

Podemos comprobar si nuestros dispositivos  están afectados por este fallo























Descargando e instalando esta aplicación de los chicos de Curesec.  
  CRT-Kolme.apk (aplicación de prueba)

Después de la instalación basta con hacer clic sobre el logotipo de Curesec y la testscreen aparecerá.Elegimos el SDK que desea probar. Si su teléfono es vulnerable, se llamará al número 31337.
Podemos hacer uso del exploit en remoto con Drozer.


 Descarga Drozer aquí

 dz_exploit (exploit archive cve-2013-6271, cve-2013-6272 and cve-2014-n/a)

tar xjf dz_exploits.tar.bz2 -C drozer/modules
adb forward tcp:31415 tcp:31415
drozer console connect

dz> run curesec.exploit.callme2 -tdz> run curesec.exploit.callme1 -k kill 





FUENTES:


















jueves, 7 de agosto de 2014

Instalar Arch Linux y Kali Linux en Raspberry Pi (arranque dual con BerryBoot)

Hace poco comentábamos en una breve entrada que Kali Linux, el nuevo BackTrack, incluye soporte ARMEL, es decir, puede instarlarse en Raspberry Pi (Diego Cardanha nos pedía además un mini-tutorial...)

Si has leído algunas entradas anteriores sobre RPi en el blog (www.hackplayers.com), sabes que estaba jugando principalmente con la distro Arch Linux, por lo que vamos a mantenerla y aprovechar para instalar dos sistemas operativos en una misma tarjeta SD: Arch Linux y Kali Linux.


Para ello vamos a utilizar BerryBoot, un administrador de multi-arranque que nos facilitará el proceso. 


Instalando BerryBoot


La instalación es sumamente sencilla: simplemente descarga el instalador y descomprime el zip en una tarjeta SD con formato FAT.


Al encender la RPi aparecerá la siguiente ventana de bienvenida para calibrar la pantalla, seleccionar el tipo de conexión y la configuración regional:

A continuación seleccionaremos como disco la tarjeta SD para formatearla:
Después de aproximandamente un minuto, nos aparecerá otra pantalla para seleccionar el SO a instalar:
Pulsaremos cancelar puesto que ninguno de los dos sistemas operativos que queremos instalar se encuentran disponible, así que tendremos que añadirlos manualmente. Para ello tendremos que adquirir cada una de las imágenes correspondientes y convertirlas a formato SquashFS, un sistema de archivos comprimido de sólo lectura para Linux, que BerryBoot combina con aufs (AnotherUnionFS) para disponer de un entorno de lectura-escritura. De esta manera se obtienen las ventajas de la alta velocidad de compresión de SquashFS con la posibilidad de alterar la distribución mientras se ejecuta desde la tarjeta SD (liveCD).

Primero necesitaremos un entorno Linux (en mi caso Debian) para realizar todas las operaciones e instalar los siguientes paquetes si no se disponen de ellos previamente:

apt-get install squashfs-tools  kpartx 

Preparando la imagen de Arch Linux

Empezaremos descargando y descomprimiendo la imagen de Arch Linux



prueba@islatortuga:~$ unzip archlinux-hf-2013-02-11.zip
Archive:  archlinux-hf-2013-02-11.zip
  inflating: archlinux-hf-2013-02-11.img 

prueba@islatortuga:~$ file archlinux-hf-2013-02-11.img
  archlinux-hf-2013-02-11.img: x86 boot sector; partition 1: ID=0xc, active, starthead 64, startsector 2048, 184320 sectors; partition 2: ID=0x83, starthead 0, startsector 186368, 3481600 sectors, code offset 0xb8

Ahora utilizaremos kpartx, una utilidad para montar las particiones de un archivo imagen de disco. Con la opción -a diremos que las particiones en el archivo se vuelvan accesibles a través del device mapper, en la ruta /dev/mapper/loop0pX (donde X es el número de la partición). La opción -v es verbose ;):


root@islatortuga:/home/prueba# kpartx -av archlinux-hf-2013-02-11.img 
add map loop0p1 (254:0): 0 184320 linear /dev/loop0 2048
add map loop0p2 (254:1): 0 3481600 linear /dev/loop0 186368

Después montamos la partición 2 en /mnt:


root@islatortuga:/home/prueba# mount /dev/mapper/loop0p2 /mnt

Con el siguiente comando simplemente comentaremos la línea del fichero fstab:


root@islatortuga:/home/prueba# sed -i 's/^\/dev\/mmcblk/#\0/g' /mnt/etc/fstab

Si convirtiéramos ya la imagen nos encontraríamos con un desagradable mensaje durante el arranque: 


Error: having a symlink for /lib and/or /sbin inside your image is not allowed!
This conflicts with the shared AUFS folders
...
switch root: can't execute '/sbin/init': no such file or directory
...

Esto es debido a que con las últimas actualizaciones en Arch Linux todos los archivos del directorio /lib han sido movidos a /usr/lib y ahora /lib es un enlace simbólico a usr/lib:
root@islatortuga:/home/prueba# ls -las /mnt/lib
0 lrwxrwxrwx 1 root root 7 Dec 30 22:01 /mnt/lib -> usr/lib

Al no permitirse estos enlaces simbólicos, el directorio /lib y las librerías compartidas de glibc (ficheros .so) no son accesibles y (entre otros problemas) no se pueden ejecutar binarios como "init", en System V el primer proceso en ejecución tras la carga del kernel y el que a su vez genera todos los demás procesos, y por lo tanto no hay arranque...

Como workaround borraremos el enlace y duplicaremos los directorios, luego más adelante veremos como actualizar el sistema (systemd) y corregirlo:



root@islatortuga:/home/prueba# rm /mnt/lib && cp -r /mnt/usr/lib/ /mnt/lib

Ahora finalmente para convertir la imagen en formato squashfs ejecutaremos el siguiente comando (omitiendo el directorio /lib/modules y seleccionando compresión lzo):



root@islatortuga:/home/prueba# mksquashfs /mnt archlinux-hf-2013-02-11_berryboot.img  -comp lzo -e lib/modules
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on archlinux-hf-2013-02-11_berryboot.img, block size 131072.
[===========================================================|] 25865/25865 100%
Exportable Squashfs 4.0 filesystem, lzo compressed, data block size 131072
    compressed data, compressed metadata, compressed fragments, compressed xattrs
    duplicates are removed
Filesystem size 172472.18 Kbytes (168.43 Mbytes)
    50.48% of uncompressed filesystem size (341693.74 Kbytes)
Inode table size 391330 bytes (382.16 Kbytes)
    34.95% of uncompressed inode table size (1119672 bytes)
Directory table size 389368 bytes (380.24 Kbytes)
    54.23% of uncompressed directory table size (718049 bytes)
Xattr table size 43 bytes (0.04 Kbytes)
    53.75% of uncompressed xattr table size (80 bytes)
Number of duplicate files found 2926
Number of inodes 32818
Number of files 26548
Number of fragments 1281
Number of symbolic links  2883
Number of device nodes 3
Number of fifo nodes 1
Number of socket nodes 0
Number of directories 3383
Number of ids (unique uids + gids) 6
Number of uids 2
    root (0)
    unknown (87)
Number of gids 6
    root (0)
    unknown (11)
    tty (5)
    unknown (81)
    staff (50)
    unknown (87)

Y ya tenemos la imagen que debemos guardar en un pendrive USB:



root@islatortuga:/home/prueba# du -h archlinux-hf-2013-02-11_berryboot.img 
169M    archlinux-hf-2013-02-11_berryboot.img
root@islatortuga:/home/prueba# file archlinux-hf-2013-02-11_berryboot.img
archlinux-hf-2013-02-11_berryboot.img: Squashfs filesystem, little endian, version 4.0, 176611513 bytes, 32818 inodes, blocksize: 131072 bytes, created: Wed Mar 20 11:51:48 2013

Finalmente desmontamos el directorio y liberamos la imagen:



root@islatortuga:/home/prueba# umount /mnt
root@islatortuga:/home/prueba# kpartx -d archlinux-hf-2013-02-11.img
loop deleted : /dev/loop0

Preparando la imagen de Kali Linux

No comentaré cada paso porque la preparación de la imagen de nuestra distro de pentesting favorita es igual que la anterior, exceptuando que no es necesario realizar ninguna modificación para el directorio /lib.



root@islatortuga:/home/prueba# gzip -d kali-linux-1.0-armel-raspberrypi.img.gz
root@islatortuga:/home/prueba# du -h kali-linux-1.0-armel-raspberrypi.img
4.7G    kali-linux-1.0-armel-raspberrypi.img
root@islatortuga:/home/prueba# file kali-linux-1.0-armel-raspberrypi.img
kali-linux-1.0-armel-raspberrypi.img: x86 boot sector; partition 1: ID=0xc, starthead 0, startsector 1, 125000 sectors; partition 2: ID=0x83, starthead 2, startsector 125001, 9640624 sectors, code offset 0xb8
root@islatortuga:/home/prueba# kpartx -av kali-linux-1.0-armel-raspberrypi.img
add map loop0p1 (254:0): 0 125000 linear /dev/loop0 1
add map loop0p2 (254:1): 0 9640624 linear /dev/loop0 125001
root@islatortuga:/home/prueba# mount /dev/mapper/loop0p2 /mnt
root@islatortuga:/home/prueba# sed -i 's/^\/dev\/mmcblk/#\0/g' /mnt/etc/fstab
root@islatortuga:/home/prueba#  mksquashfs /mnt kali-linux-1.0-armel-raspberrypi_berryboot.img  -comp lzo -noappend
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on kali-linux-1.0-armel-raspberrypi_berryboot.img, block size 131072.
[=========================================================|] 173291/173291 100%
Exportable Squashfs 4.0 filesystem, lzo compressed, data block size 131072
    compressed data, compressed metadata, compressed fragments, compressed xattrs
    duplicates are removed
Filesystem size 1769950.50 Kbytes (1728.47 Mbytes)
    45.82% of uncompressed filesystem size (3863118.06 Kbytes)
Inode table size 2658319 bytes (2596.01 Kbytes)
    35.52% of uncompressed inode table size (7483443 bytes)
Directory table size 2254716 bytes (2201.87 Kbytes)
    48.19% of uncompressed directory table size (4678974 bytes)
Number of duplicate files found 9490
Number of inodes 202989
Number of files 154198
Number of fragments 9813
Number of symbolic links  34690
Number of device nodes 37
Number of fifo nodes 1
Number of socket nodes 0
Number of directories 14063
Number of ids (unique uids + gids) 26
Number of uids 10
    root (0)
    usbmux (104)
    man (6)
    iodine (111)
    miredo (105)
    avahi (108)
    nobody (65534)
    messagebus (102)
    www-data (33)
    libuuid (100)
Number of gids 24
    root (0)
    fuse (104)
    tty (5)
    kmem (15)
    disk (6)
    adm (4)
    ntp (111)
    shadow (42)
    haldaemon (119)
    pulse-access (118)
    bluetooth (108)
    nogroup (65534)
    utmp (43)
    utempter (109)
    crontab (102)
    avahi (115)
    mysql (103)
    messagebus (106)
    netdev (110)
    staff (50)
    www-data (33)
    colord (107)
    libuuid (101)
    mail (8)
root@islatortuga:/home/prueba# umount /mnt
root@islatortuga:/home/prueba# kpartx -d kali-linux-1.0-armel-raspberrypi.img
loop deleted : /dev/loop0
root@islatortuga:/home/prueba# du -h kali-linux-1.0-armel-raspberrypi_berryboot.img
1.7G    kali-linux-1.0-armel-raspberrypi_berryboot.img
root@islatortuga:/home/prueba# file kali-linux-1.0-armel-raspberrypi_berryboot.img
kali-linux-1.0-armel-raspberrypi_berryboot.img: Squashfs filesystem, little endian, version 4.0, 1812429316 bytes, 202989 inodes, blocksize: 131072 bytes, created: Wed Mar 20 09:11:26 2013

Añadiendo los dos sistemas operativos en Berryboot

Una vez que ya tenemos las dos imagenes preparadas (archlinux-hf-2013-02-11_berryboot.img y kali-linux-1.0-armel-raspberrypi_berryboot.img) las copiaremos a unpendrive USB, lo conectaremos a la RPi y en el menú de inició situaremos el cursor y dejaremos pulsado el botón hasta que se despliege la opción "Copy OS from USB stick" (disculpar por la calidad de las imágenes, hice las fotos borracho un sábado de madrugada):



A continuación seleccionaremos cada uno de los archivos:



 Y haremos favorito el que deseemos. El resultado final es el siguiente:


Posteriormente tendremos que hacer algunas tareas post-instalación básicas, como el redimensionamiento de las particiones para aprovechar el espacio disponible de la tarjeta SD, actualización del software de sistema, creación de usuarios no root, sincronización de la hora, etc. pero eso ya lo dejo en sus manos y/o será descrito en futuros artículos ;)

Fuente

martes, 5 de agosto de 2014

Instasheep: secuestrar cuentas de Instagram en una red Wi-Fi


Stevie Graham, un programador de Londres, presentó recientemente un informe a Facebook describiendo lo que él veía como una vulnerabilidad en Instagram que podía permitir a alguien secuestrar la sesión de un usuario en base a los datos capturados a través de una red Wi-Fi pública.

Cuando Facebook le dijo que no iba a obtener una recompensa por el bug, Stevie se dedicó a preparar una herramienta de prueba de concepto para explotarla. "Denegado el programa de recompensas. El siguiente paso es escribir una herramienta automatizada que permite el secuestro masivo de cuentas", escribió. "Vuln bastante grave, FB. por favor arreglarla".

Instagram utiliza HTTP para gran parte de sus comunicaciones, transmitiendo en claro el nombre de cuenta del usuario y el id. Y como Graham demostró, hay otros datos que se envían entre el cliente iOS de Instagram y el servicio que se pasan en claro.

A pesar de que las credenciales del usuario se envían utilizando una conexión segura, la información pasa de nuevo por la interfaz de la aplicación de Instagram al teléfono y proporciona una cookie que se puede utilizar en la misma red sin reautenticación para conectar a través de la Web a Instagram como ese usuario y tener acceso a mensajes y otros datos. "Una vez que tenga una cookie, cualquier punto final puede ser autenticado con la cookie, HTTPS o HTTP", comentó. Stevie dijo también que él conocía este fallo durante años.

Graham ha publicado los siguientes pasos para reproducir el exploit:

- conecta con un punto de acceso abierto o WEP

- pon el interfaz en modo promiscuo y filtra i.instagram.com: sudo tcpdump -In -i en0 -s 2048 -A dst i.instagram.com

- espera a que alguien con iOS use Instagram

- extrae la cookie de la cabecera de la petición del resultado de la salida

- utiliza el parámetro de la cookie sessionid para cualquier llamada al api (incluido https y mensajes directos):

    curl -H 'User-Agent: Instagram 6.0.4 (iPhone6,2; iPhone OS 7_1_1; en_GB; en-GB) AppleWebKit/420+' \ -H 'Cookie: sessionid=REDACTED' \  https://i.instagram.com/api/v1/direct_share/inbox/`

Esto nos llevará a la bandeja de entrada de mensajes directos del usuario como JSON (JavaScript Object Notation).

Como veis este tipo de exploit es similar a "Firesheep" y por eso Stevie llamó a su herramienta "Instasheep". Aunque de momento seguimos esperando su código en su repositorio: https://github.com/stevegraham/instasheep.

Fuentes: 
Instasheep: Coder builds tool to hijack Instagram accounts over Wi-Fi 
Using Instagram on public Wi-Fi risks account hijack


sábado, 2 de agosto de 2014

¡Borré mis chats de WhatsApp sin querer! ¿Los puedo recuperar?

Suele ser bastante común que nos pidan recuperar algunos chats de WhatsApp que han sido borrados anteriormente de forma no intencionada. Veamos primero algunas consideraciones iniciales:

- Por defecto WhatsApp realiza una copia diaria en la tarjeta SD a las 04:00 am y almacena los últimos 7 días en /sdcard/WhatsApp/Databases/msgstore.db.crypt7.   - Es posible forzar la copia del historial actual (los mensajes más recientes) de forma manual:

 WhatsApp > Botón de menú > Ajustes > Ajustes de chat > Guardar conversaciones

El fichero será guardado 
en/sdcard/WhatsApp/Databases/msgstore-AAAA-MM-DD.1.db.crypt7. 

Es decir, no podremos recuperar los mensajes con más de 7 días de antigüedad y aquellos posteriores a las 4:00 al menos que hayamos hecho previamente una copia de seguridad manual.

Para hacerlo Whatsapp nos indica cómo hacerlo fácilmente:http://www.whatsapp.com/faq/es/android/20887921.

Simplemente tendremos que reinstalar WhatsApp con el mismo número de teléfono y la aplicación detectará que hay un fichero msgstore.db.crypt7 y nos solicitará si queremos restaurar el historial. 

Si queremos que restaure una copia manual tendremos que renombrar previamente el fichero creado con un administrador de ficheros (de msgstore-AAAA-MM-DD.1.db.crypt7 a msgstore.db.crypt7).



Y bueno, si queremos llevarnos nuestra? la base de datos a otro teléfono, tendremos que llevarnos también la key y descifrarlo con whatsapp-viewer

- rooteando el teléfono y copiando /data/data/com.whatsapp/files/key
- con WhatsApp Key/DB Extractor (sin necesidad de ser root) 

Suerte y buen fin de semana!