Archivo

Enter your email address to follow this blog and receive notifications of new posts by email.

Únete a otros 116 seguidores

Twitter

Error: Twitter no responde. Por favor, espera unos minutos y actualiza esta página.

Protegiendo el acceso a tu smartphone, los acelerómetros pueden jugártela

Existen varios métodos para bloquear el acceso a tu smartphone, en las últimas versiones de Android, a los conocidos PIN, contraseña y patrón de desbloqueo, se ha añadido la posibilidad del reconocimiento facial.

El PIN consiste en cuatro dígitos numéricos, sencillo de usar, sencillo de que alguien te vea marcarlo y se quede con él para desbloqueártelo en cualquier momento.

La contraseña es más complicada al tratarse de caracteres alfanuméricos (mi preferido hasta el momento).

El reconocimiento facial… el propio sistema Android te advierte cuando intentas usarlo que no es demasiado seguro, que alguien con rasgos faciales similares podría desbloquear el móvil… o si tienes una de las primeras versiones tan solo necesitarán una foto en la que aparezcas de frente.

La cuarta opción, la del patrón de desbloqueo en su día me pareció interesante, aunque dejé de usarla (y es con la que más me voy a extender) por varias razones.

La primera es que una pantalla sucia muestra el patrón de desbloqueo con solo ponerla en el ángulo correcto contra la luz:

BAlBb7jCcAAJryF

 

La segunda era una sospecha que ha confirmado el profesor Adam j. Aviv, el pasado diciembre publicaba Practicality of Accelerometer Side-Channel on Smartphones.

Por si no os apetece leeros todo el paper os hago un breve resumen.

Este estudio muestra que es posible descifrar los patrones de desbloqueo y los números PIN de un smartphone empleando los acelerómetros que ahora todos traen de serie.

En varios test se exportó la información generada por los acelerómetros durante el proceso de dibujo del patrón de desbloqueo o durante el marcado del código PIN en el teléfono y analizada contra un “diccionario” de movimientos y clicks en pantalla obtenido previamente.

En tan solo 5 intentos, el método acertó el 43% de los PINs y el 73% de los patrones de desbloqueo, bajando este porcentaje si la captura se realizaba mientras el usuario hacia estas operaciones moviéndose, ya que eso añade “ruido” a la información obtenida por los acelerómetros.

Resumiendo, asegurad el acceso a vuestro smartphone empleando contraseña y tratando de evitar los otros 3 métodos más inseguros y que pueden ser empleados por malware en un ataque orientado a un usuario específico para hacerse con su sistema de bloqueo previamente a tener acceso físico a su teléfono y posteriormente a todo su contenido. (fin del modo paranoico)

Aunque para esto último siempre conviene tener instalado algo parecido al Avast para Android, y su módulo anti-theft.

Usando el FTP Backup de 1&1 como unidad remota montada en Linux

Si estás leyendo esto seguramente tengas algún tipo de servidor dedicado, vps o similar en 1&1, si además usas el servicio de backup ftp de esta empresa, esta información te puede ser de ayuda, sobre todo para ahorrar espacio con backups de paneles de control como el Parallels Plesk.

Imaginemos el siguiente escenario:

  • VPS con 200 GB de almacenamiento, 180 GB para /var de los cuales tenemos ocupados 90 con datos en /var/www/vhosts muchos de ellos archivos ya comprimidos en una aplicación web de gestión documental.
  • Dicho VPS está configurado con CentOS Linux 6.x x86_64 y la última versión del panel de control Parallels Plesk.
  • Tenemos contratado el servicio de backup externo de 1&1 que consiste en una cuenta de FTP con 250 GB de almacenamiento en otro servidor y que podemos configurar en el propio panel Plesk para dejar ahí nuestros backups diarios.
  • El archivo de backup comprimido ocupa 64 GB.

En estas circunstancias nos encontraremos con un problema para usar el servicio de backup automatizado de Plesk, este genera copias de seguridad de cada dominio alojado y posteriormente genera un solo archivo que es el que se pasa vía FTP al llamado Repositorio FTP Personal que apunta al servicio de FTP Backup de 250 GB.

El problema es que la suma de los archivos de backup de cada dominio ocupa 64 GB, y el archivo que es la suma de todos generado posteriormente ocupará otras 64 GB, requiriendo un total de 128 GB de espacio libre en el disco duro de nuestro servidor para poder hacer todo el proceso, tendiendo en cuenta que disponemos de unas 90GB libres en este escenario, el backup no finalizará satisfactoriamente.

Existen varias soluciones, hacernos nuestro propio script que vaya comprimiendo por dominio y pasando los datos al FTP de manera externa al panel Plesk o convertir la cuenta de FTP en una unidad montada más en nuestro sistema y hacer que el sistema automatizado de Plesk haga las copias directamente ahí, manteniendo la posibilidad de hacer recuperaciones desde el propio panel, algo bastante útil para los clientes más manazas, que podrán seguir recuperando los archivos que se han cargado sin molestarnos.

Para ello haremos uso de una utilidad llamda Curlftpfs.

Aunque es un proyecto que está bastante abandonado, sigue siendo perfectamente funcional, para ponerlo en marcha necesitaremos instalar unos cuantos paquetes antes en el sistema:

yum install gcc fuse* libcurl* glib* glibc.i686 file-libs file-devel file-static curl

Tras esto descargaremos el código fuente de Curlftpfs, lo compilaremos e instalaremos en el sistema:

cd /usr/local/src/

wget http://downloads.sourceforge.net/project/curlftpfs/curlftpfs/0.9.1/curlftpfs-0.9.1.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcurlftpfs%2Ffiles%2F%3Fsource%3Dnavbar&ts=1360498557&use_mirror=garr

tar xvfz curlftpfs-0.9.1.tar.gz

cd curlftpfs-0.9.1

./configure

make

make install

Nota: la última versión de curlftps es la 0.9.2, se usa la 0.9.1 porque no da los problemas que sí da la última versión en CentOS 6.x 64 bits, sobre todo en temas de reconexión.

Guardaremos los datos de acceso al ftp en el archivo /root/.netrc (root es el usuario que ejecuta el backup de Plesk):

machine backupXXX.onlinehome-server.info
login bakXXXXX
password MICLAVE

Nos aseguramos de que nadie más que root pueda ver los datos y creamos el punto donde montaremos la cuenta de FTP:

chmod 600 /root/.netrc
mkdir /mnt/backupftp

El sistema ya está listo para montar la cuenta de ftp como si de otra unidad del sistema se tratase, no vamos a cambiar el propietario del punto de montaje porque nos interesa que sea root quien pueda usarla por lo ya comentado, que es este usuario el que realiza el backup de Plesk:

curlftpfs backupXXX.onlinehome-server.info /mnt/backupftp -o allow_root

Si ahora hacemos un ls en /mnt/backupftp veremos el contenido de la cuenta de ftp, pudiendo copiar archivos, borrar, mover, etc como si se tratase de cualquier compartición samba o nfs.

Si queremos desmontar la unidad:

fusermount -uz /mnt/backupftp

Pero no queremos, así que ahora pasaremos a cambiar algunas cosas en el sistema para no tener que cambiar la configuración base de Plesk, ya que pued suponer un problema cuando el software del panel de control se actualiza.

Moveremos el directorio donde se realizan las copias de seguridad a la  nueva unidad:

cd /var/lib/psa

cp -r dumps /mnt/backupftp/

Si el proceso de copia ha sido satisfactorio:

rm -rf dumps

ln -s /mnt/backupftp/dumps/ dumps

Movido el directorio creamos el enlace simbólico para que Plesk siga encontrando /var/lib/psa/dumps, aunque ahora estará haciendo las copias de seguridad directamente contra nuestra cuenta de FTP Backup.

En el panel de control Plesk, menú Herramientas y Configuración, Administrador de Backups, pincharemos en el botón Configuración de Backups Programados y seleccionaremos la opción Guardar Backup en Repositorio del Servidor:

Configuración de Backups Programados

El número máximo de backups en el repositorio depende de cuanto ocupe nuestro backup y el espacio libre del que dispongamos en el FTP.

Y listo, nos podemos despreocupar de los problemas de espacio que hemos tenido previamente.

BOLA EXTRA

Para que la nueva unidad se monte automáticamente al reiniciar el servidor podemos añadir a /etc/fstab la siguiente línea:

curlftpfs#backupXXX.onlinehome-server.info /mnt/backupftp fuse rw,user,noauto,allow_root 0 0

Podemos encontrarnos con problemas de espacio por el uso de temporales que hace Plesk, /usr/local/psa/PMM/tmp por ejemplo, que podemos borrar, y enlazar con ln a un temporal dentro de /var que es donde disponemos de más espacio o bien directamente también contra la unidad montada de FTP.

OJO: antes de borrar el directorio dumps o este tmp, detén el servicio psa:

/etc/init.d/psa stop

Cuando finalices debes volver a iniciarlo.

Impresoras HP accesibles desde Internet y ataques de modificación de firmware

El buscador de Google es una herramienta muy útil para encontrar vulnerabilidades y no me estoy refiriendo solo a exploits, info de CVE, etc.

Trasteando por la red he dado con una consulta muy interesante en Google:

inurl:hp/device/this.LCDispatcher

Los resultados devueltos son el panel de control de miles de impresoras HP alrededor de todo el planeta, que entre otras cosas permite imprimir archivos .ps en remoto, algunas otros tipos de archivos como .txt, y muchas de ellas actualizar firmware, cambiar la configuración de la impresora, etc.

En IronGeek muestran varias acciones que se pueden llevar a cabo con estas impresoras, algunas en remoto dependiendo de la configuración del firewall de la red, que visto que dejan salir al exterior a las impresoras sin ningún control, no auguran nada bueno.

En los resultados de Google hay muchas direcciones IP que habría que investigar, mirando por encima y tirando de Ripe he dado con 3 universidades españolas y un par de empresas extranjeras.

Pantallazo

Universidad Politécnica de Madrid

La primera impresora elegida al azar del listado de Google pertenece a la Universidad Politécnica de Madrid.

Pantallazo-4

En la página de estado de la impresora vemos que el firmware es de 2010, en la página de soporte de HP la última versión del firmware de esta impresora es de 2012, más allá de que puedan existir vulnerabilidades en ese firmware, lo realmente preocupante es la posibilidad de modificarlo e instalar uno con malware como se mostró en el 28th Chaos Communication Congress.

Otras impresoras no ha sido necesario buscar la IP en Ripe, en la propia url muestran que pertenecen a la Escuela de Ingenieros de la Universidad de Valladolid:

Pantallazo-2

Y suma y sigue, Universidad de los Andes, el MIT, la Universidad de Valencia… la lista es interminable.

Comprueba si tu impresora, HP o de otra marca, está visible en la red de redes, no vayas a estar dejando una puerta de entrada remota a un atacante.

Si os entrar el ansia de imprimir algo en remoto, aprovechad para echar una mano a aquellos que no se han dado cuenta de que tienen este problema enviándoles a imprimir este archivo… Vale, no es divertido el contenido, pero ya sabes eso de hoy por ti, mañana por mi.

 

MEGA, mucho marketing y pocas nueces

Tras muchas horas de intentos infructuosos he logrado tener acceso al nuevo invento de Kimi DotCom, Mega, un presunto Dropbox con esteroides que no han sabido dimensionar para su presentación en sociedad. Mucho marketing y poca máquina por muy beta que ponga junto al nombre. La fecha de la presentación en sociedad de Mega no es trivial, coincide con el aniversario de la detención de Kim Dotcom por el caso de violación de derechos de autor con su anterior servicio, MegaUpload.

Mega

Mega se anuncia como “La empresa de la privacidad, más grande, mejor, más rápida, más fuerte, más segura”, un buen reclamo para usuarios y empresas que quieran tener una copia de seguridad de sus datos en la red de manera segura.

Más grande sí, son los primeros en ofrecer 50GB de espacio gratuito. el resto, incluyendo el tema de la privacidad… vamos a ponerlo en cuarentena.

Existe vida antes de MegaUpload y Kim DotCom tiene un largo historial delictivo, desde traficar con tarjetas telefónicas antes de la mayoría de edad hasta comprar acciones de una empresa próxima a la bancarrota, anunciar que iba a invertir $50 millones que no tenía en ella para rápidamente vender las acciones en cuanto estas aumentaron su valor.

Se supone que fue un hacker mítico que incluso llegó a fundar una empresa de seguridad… ahora es más conocido por sus excesos de nuevo rico, desde sus fiestas en Mónaco hasta su participación en la carrera ilegal para ricos Gumball 3000, la cual ganó en 2001.

Más info de su carrera en la Wikipedia en inglés.

Desde aquellos prometedores inicios hasta la aparición de Mega ha pasado mucho tiempo y nos encontramos con algunos fallos que no parecen propios de alguien con esos supuestos conocimientos.

Lo primero que llama la atención son los términos de servicio de Mega, este está diseñado para que los archivos estén cifrados y todo se haga del lado del cliente, llegando a sus servidores ya cifrados los archivos. Esto les libera de toda responsabilidad en caso de que alguien suba archivos protegidos por derechos de autor.

Al estar cifrado con una clave privada para cada usuario, solo este puede descargar sus propios archivos, salvo que con el enlace incluya la clave de ese archivo, por ejemplo:

https://mega.co.nz/#!vNF2xTja

Este enlace nos lleva a la página de descarga (no necesita registro) pero nos pedirá la clave del archivo para descifrarlo, para descargar el archivo directamente debería incluir la clave en la url o que el destinatario la tuviera por otro método:

https://mega.co.nz/#!vNF2xTja!Qr2ZXy6gaVSDhacAnhTZuX-n-3YWKgU5h4-5QrdMArA

En este caso descargará el archivo prueba.txt tras aceptar los términos de servicio.

Podría servir como sitio para intercambiar archivos al estilo MegaUpload, pero con estos enlaces las autoridades puedes ver también que hay y solicitar a Mega el borrado de ese enlace, con la plena colaboración por parte de la empresa tal y como expresa en el punto 19 de sus términos de servicio, incluyendo facilitar los datos del usuario, la IP desde la que se conecta

Un punto que ha generado bastante controversia es el 8º:

8. Our service may automatically delete a piece of data you upload or give someone else access to where it determines that that data is an exact duplicate of original data already on our service. In that case, you will access that original data.

Aunque el CEO ya ha dado explicaciones indicando que se trataría tan solo de casos en los que el mismo usuario subiese 2 veces el mismo archivo a su cuenta, existen dudas en la red sobre este punto.

La gran duda es si se está usando cifrado convergente para evitar archivos duplicados.

Servicios bien conocidos como Dropbox también usan cifrado en sus archivos, AES-256, más potente que el AES-128 que usa MEGA. (AES-128 está aprobado por EE.UU para ser usado en documentos hasta nivel de Secreto, para los Secret y Top Secret recomiendan usar  AES-192 y AES-256.

La diferencia, además de la fortaleza del algoritmo de cifrado de archivos, es que Mega cifra el contenido en el lado del usuario y el servidor ya lo recibe cifrado, mientras que Dropbox lo transmite sin cifrar (por canal seguro https) y es cifrado en el servidor usando una clave maestra, que suele ser un hash del propio archivo, que lo identifica de forma única como una huella digital.

De esta manera cuando vamos a subir un archivo a Dropbox, este primero envía el hash para comprobar que el archivo no existe ya, si no existe lo carga en el servidor, genera el hash y en nuestra cuenta aparece el archivo con el nombre que nosotros le hemos dado. Pero si el archivo ya existe, la carga no se produce y tan solo se limita a enlazar una entrada en nuestra cuenta con ese hash y el nombre del archivo que le hemos asignado.

Si tenéis 2 cuentas de Dropbox lo podéis comprobar vosotros mismos, subís un archivo de, por ejemplo, 10Mb llamado prueba1.zip en una de las cuentas, veréis que tarda un rato en transmitir los datos. Si ahora entráis en la 2ª cuenta y tratáis de subir el mismo archivo con otro nombre, por ejemplo renombrándolo antes de subirlo a pruebadrop.zip, la carga parece ser instantánea.

En ambas cuentas habréis consumido 10 Mb de espacio y tendréis un archivo llamado prueba1.zip y pruebadrop.zip respectivamente, pero realmente al servidor solo se han subido 10 Mb de datos, ahorrando consumo de ancho de banda y de espacio de almacenamiento para la empresa que ofrece el servicio.

Esta es una práctica común que parece poco probable que esté implementada en Mega por las pruebas que he realizado a falta de inspeccionar el código javascript y los métodos de cifrado que usa, para descartar que del lado del servidor haya posibilidad de realizar un descifrado o algún método de comparar hash entre cuentas de diferentes usuarios, de ser así, esto facilitaría la labor de la industria de contenidos para eliminar todas las copias de un archivo que ellos indiquen que está protegido por derechos de autor.

Existen otros servicios, algunos de empresas de renombre y que luego enumeraré, que emplean sistemas de cifrado seguro como el de Mega, es decir, que cifran los archivos antes de enviarlos

Las prisas son malas consejeras y más cuando estás desarrollando algo por primera vez… o eso es lo que se desprende del segundo párrafo del manual para desarrolladores de Mega:

(it is also our first JavaScript project, so please bear with us)

Javascript es el lenguaje de programación empleado por Mega para hacer el único cliente que permite acceder a sus servicios y que es parte de la propia web.

El manual es pobre en descripción y pone como ejemplo el propio código de la web que está sin comentararios y sin una estructura decente como ellos mismos reconocen.

Es decir, que de momento nos podemos olvidar de aplicaciones como la de Dropbox o similares para PC, MAC y smartphones con la que poder cargar y descargar nuestros archivos de una manera cómoda, sincronizar carpetas de nuestro ordenador con nuestro espacio en Mega, etc.

Volvemos a las prisas y a que sea su primer proyecto en javascript y nos encontramos con algunos problemas a nivel técnico que, desde mi punto de vista, minan la confianza en este servicio:

1.- Las claves de cifrado son generadas por Javascript en el navegador del usuario la primera vez que accede. Uno de los problemas es la generación de números aleatorios, los ordenadores generan números pseudo-aleatorios que pueden ser “adivinados” (esto no es sencillo, pero ya ha resultado un problema anteriormente), para generar más aleatoriedad, se debe generar entropía, en el caso de Mega lo hacen detectando los movimientos de ratón y pulsaciones de teclado durante el proceso de generación de la clave.

Si el usuario no es consciente de esto y se queda mirando a la pantalla no se añade entropía alguna a la clave, la cual además dependerá en última instancia de la contraseña elegida para acceder al servicio.

Echándole un poco de imaginación, en lugar de depender de los movimientos del ratón o pulsaciones del teclado, podían haber usado la librería seedrandom y algún generador aleatorio basado en cosas tan dispares como la desintegración de átomos o bien el sonido ambiente que captan varios micrófonos como el que ofrecen en random.org.

Respecto a la clave elegida para acceder al servicio, tan solo se limitan a mostrarte si tu clave es débil, normal o fuerte, obviando recomendaciones importantes para este tipo de servicios, como que es preferible usar una clave de 20 caracteres que una de 8 por mucho que la segunda incluya mayúsculas, minúsculas y números y la primera solo sea una cadena larga de palabras concatenadas.

2.- En el email que recibimos al darnos de alta viene un enlace para confirmar el proceso.

Dicho enlace incluye una huella hash de nuestra propia clave con la que nos dimos de alta en el servicio, además de nuestra master key usada para descifrar los archivos que subamos a Mega:

Esto implica que alguien que tenga acceso a nuestro correo y se descargue la herramienta MegaCracker, puede llegar a tener acceso a nuestra contraseña y master key, aunque es posible que otras aplicaciones como HashCat puedan hacerlo de manera más eficiente.

3.- Mega es (esperemos que cuando publique esto lo hayan solucionado) vulnerable a ataques de Cross Site Scripting como demostró el usuario de Twitter @StackSmashing:

Mega XSS Bug

 

4.- A pesar de que Kim anunció en su momento que Mega estaría alojado en servidores en Nueva Zelanda, la realidad parece ser que es otra, probando desde diferentes localizaciones la mayor parte de los servidores parecen estar en el centro de datos que tiene Cogent en Kansas: http://www.datacenter9.com/datacenter/cogent-kansas-city-891

Esto implica que están muy a mano para las autoridades americanas, lo que unido a que el código Javascript se descarga desde sus servidores cada vez que accedemos a la web para ejecutar el cifrado de los datos, puede ser manipulado sin previo aviso para interceptar las comunicaciones de uno o varios usuarios y que las autoridades puedan acceder a sus datos, por mucho que la empresa esté en Nueva Zelanda y diga ajustarse a la legislación de ese país.

Si alguien necesita una explicación más técnica, la gente de fail0verflow la desarrolla en su blog.

5.- Si activas la opción “recordarme” para no tener que volver a meter tus datos de acceso la próxima vez que visites Mega, tu clave maestra de cifrado queda almacenada en el disco duro de tu ordenador sin cifrar, visible por cualquiera que tenga acceso a la carpeta Local Storage de tu navegador web Chrome.

Y más cosas que me voy a dejar en el tintero como la pobre implementación de la función de derivación de clave, si alguien quiere que lo cuente con código y datos, que lo diga en los comentarios, que solo eso me da casi para otro post.

Resumiendo, Mega es un servicio que se ha creado centrándose en la seguridad de la empresa, no del usuario, con un montón de fallos por las prisas de la simbólica fecha y por tratarse de su primera aplicación en Javascript, la cual tratan de asegurar que se carga correctamente y sin ser interceptada con un sistema muy poco seguro y que difícil solución tiene sin que del lado del cliente exista un plug-in para el navegador que pueda verificar el origen del código que se encargará de todas las operaciones de seguridad. Por no hablar de que si rompemos el cifrado SSL sobre el que el código llega hasta nuestro navegador web, podemos ser víctimas de ataques Man in the Middle para hacerse con el contenido, claves, etc que se supone viajan seguras… y con algunas implementaciones de SSL recientemente se han dado estos problemas

Si ya hay pocos problemas de seguridad en hardware y sistemas operativos, en este caso tenemos que añadir una capa más de presuntos problemas, el navegador web, totalmente necesario para acceder a este servicio.

Y ahora hablando en plata, además de los conocidos servicios de descarga de películas por torrent, buscadores de estos archivos, webs de series con visionado online, existen servicios privados en servidores a los que solo se tiene acceso por recomendación de un conocido y con precios que oscilan los 20-25€ por persona al mes para hacer frente a los gastos de servidores, tiempo de la gente que sube las cosas, etc.

He visto algunos de esos servicios, que disponen de un interfaz web muy sencillo que permite navegar por los archivos de películas, series, software, videojuegos, etc almacenados en uno o más servidores y descargarlos en nuestro ordenador.

Viendo que la API de Mega, el precio de 2TB de espacio de almacenamiento al mes y demás, no sería descabellado pensar que el target de usuario de pago sea ese tipo de servicios de descargas, que se ahorrarían dinero en almacenamiento y podrían modificar el interfaz web para que al seleccionar que queremos descargar, la cuenta de pago pase el enlace al contenido elegido y luego tan solo tengamos que entrar a nuestra cuenta gratuita a descargar la película o videojuego que nos apetezca…

Si no necesitas tanto espacio o “seguridad”, Dropbox sigue siendo una alternativa interesante y cómoda de usar para almacenar copias de seguridad en la red y compartir archivos.

Si eres una empresa que quiere estos servicios que ofrece Dropbox pero con mayor seguridad…  Mega no ha inventado nada nuevo, hay empresas que llevan más tiempo haciendo lo mismo o parecido, aunque no ofrecen tanto espacio gratis, algunas tan solo una prueba gratuita de 30 días, estas son mis recomendaciones:

iDrive

Ofrecen 5 GB gratuitos, puedes conseguir 10 GB adicionales permitiendo que envíen publicidad a los contactos de tu cuenta de email, así como por recomendar el servicio.

Disponen de cliente para Windows, Mac, Linux, Android e iPhone/iPad

La aplicación permite elegir que carpetas o archivos queremos incluir en el backup, ofrece PDC (Protección de Datos Continua) y acceso a las últimas 30 versiones de un archivo, es decir, que si nos cargamos parte del texto de un documento, podremos recuperar la versión previa del backup.

Los datos son cifrados antes de ser enviados al servidor, permite dos métodos, usando el cifrado “Default”, los archivos son cifrados usando una master key común, al estilo de Dropbox, permitiendo a la empresa acceso a ver el contenido de nuestros archivos si así lo deseasen. Por otra parte está el cifrado “Privado”, en el que especificaremos una clave (que sea lo suficientemente larga y que podáis recordar) para cifrar los archivos.

Ojo, si perdemos esa clave, no podremos recuperar los archivos, habría que definir otra clave, borrar los archivos y crear un nuevo backup en nuestro espacio.

Permite compartir archivos con otros usuarios, pero solo en el modo de cifrado “Default”, con el modo Privado solo nosotros o a quien demos la clave que usamos para cifrar, podrá acceder a los contenidos.

iDriveSync

Esta es la versión de “consumo” de iDrive, dispone de cliente para Windows, Mac, Linux, Android, iPhone/iPad y vía web puede integrarse con Facebook.

Dan gratis 10GB (11GB si pinchas en este enlace) pudiendo conseguir gratis hasta un total de 30GB por referenciar a otros usuarios, instalar la app móvil, etc.

Adicionalmente permite acceder por WebDAV (permite montar la cuenta como una unidad más de nuestro ordenador) y tener un grupo de carpetas sincronizadas como Dropbox.

También permite seleccionar cifrado “Default” o “Privado”, al menos desde la app para Linux, con las mismas restricciones para poder compartir que iDrive.

Comodo Cloud

Comodo, empresa que desde hace años se dedica al mundo de la seguridad, desde certificados SSL a antivirus, ofrece 5 GB gratis, los archivos son cifrados antes de ser enviados al servidor.

Dispone de aplicación para Windows y Android, y el respaldo de una empresa con una muy buena reputación.

Wuala

Propiedad del fabricante de dispositivos de almacenamiento LaCie, Wuala ofrece 5GB de manera gratuita, con las mismas funcionalidades de Dropbox pero con cifrado de los archivos en el cliente con AES-256 y también la posibilidad de compartir ficheros usando una clave RSA de 2048 bits, bastante parecido a Mega y su AES-128 y RSA de 2048 bits para compartir archivos.

SafeSync

Con la experiencia de Trend Micro, creador de antivirus y otras herramientas de seguridad.

No ofrecen espacio gratuito, tan solo una prueba de 30 días, tras las cuales el plan mínimo es de 20GB por $39,95 al año

 

Rompiendo el sistema de cifrado definitivo antes de que salga

Ampliando: Os recomiendo leer esta entrada en Naukas, el autor también es físico y se ha tomado en serio diseccionar la solicitud de patente en lugar de reírse del autor y de los periodistas que le han dado pábulo.

Hace apenas una hora me he topado con esta noticia en Barrapunto, Investigador español presume de crear el algoritmo de cifrado definitivo.

De ahí paso por la noticia que enlaza en El Mundo, Un físico reta a los hackers y vía Google por Patente valenciana antipiratas. Aquí el texto de la solicitud internacional de patente.

Rebusco un poco más y me encuentro que en Kriptópolis apuntan a una posible vulnerabilidad… Os seré sincero, tras leer las noticias y un vistazo rápido a la patente , me quedé sin ganas de leer la explicación de Kriptópolis… para matemáticos y físicos resultará interesante, para un administrador de sistemas resulta aburrido e irrelevante para conseguir romper este sistema de cifrado “definitivo”.

Resumiendo el sistema bastante, se trata de cifrar un mensaje en base a dos claves, una de ellas llamada de procedimiento, la primera parece ser una tabla de equivalencias basada en la teoría de residuos.

Bueno, no se muy bien si es así exactamente, lo he leído por encima en la solicitud de patente y he perdido el interés al encontrarme un ladrillazo como este:

Por lo que respecta a los sistemas de cifrado simetrico, uno de los lenguajes mas solventes continua siendo el llamado algoritmo DES (Data Encryption Standard)

Primera pista, alguien que dice haber creado el algoritmo de cifrado definitivo no tiene ni idea de algoritmos de cifrado.

DES, con una longitud de clave muy pequeña (56 bits) y desarrollada en los años 70, ya se rompía mediante fuerza bruta durante los 90, en el 98 hicieron falta solo 56h para romperlo, y la potencia de los ordenadores por aquel entonces era ridícula comparada con la que tenemos hoy en los teléfonos móviles.

En la propia patente viene un dibujo con el funcionamiento:

algoritmodefinitivo

Se trata de un sistema de cifrado simétrico en el que emisor y receptor deben ponerse de acuerdo antes en cual será la clave de ls tabla de equivalencias y la clave de protocolo, sin especificar como se pondrán de acuerdo ambos… ¿una libreta de claves (pero digital) al estilo de las que usaba la máquina Enigma del ejército alemán?

Segunda pista, este hombre puede ser un teórico fantástico, un físico de renombre, pero desconoce bastante el funcionamiento de los ordenadores.

Imaginemos por un instante que he entendido como funciona y se implementa el algoritmo, que no he leído el enlace anterior de Kriptópolis y que acepto el reto de este hombre.

Como no soy un experto en algoritmos de cifrado a nivel matemático ni me molesto en calcular el tiempo que me llevaría romper la clave por fuerza bruta, así que recurriremos a algo mucho más sencillo y ya no tan sofisticado:

1.- Interceptar las comunicaciones para obtener el mensaje cifrado.

2.- Mediante ingeniería social hacer que el destinatario se instale un troyano, un keylogger y algún programa para volcar la memoria de la máquina a disco adaptado para que se ejecute cuando se abra el programa de descifrado.

Si disponemos de acceso a la máquina podemos emplear algún ataque usando un Firewire, porque al final, por muy complicado que sea este sistema, al ser descifrado por el receptor, requerirá de una aplicación que cargue en memoria las tablas y el código del protocolo, además de necesitar que el usuario ponga cualquier otro tipo de clave adicional para hacerlo funcionar.

En algún momento, además de disponer en memoria de las tablas, tendremos también el texto descifrado en memoria, pudiendo acceder de manera relativamente sencilla a ellos, sobre todo comparado con un ataque por fuerza bruta contra algo que se supone que tiene infinitas combinaciones a la hora de cifrar el contenido.

En el caso de usar este sistema para evitar la piratería de contenidos, la cosa es aun más sencilla, ya que los dispositivos físicos de reproducción como un DVD deberán tener las tablas y el código de protocolo en su hardware, con lo que tarde o temprano se podrá descifrar como pasó ya con el CSS de los DVD a finales de los 90… estos dispositivos podrían conectarse a la red e ir cambiando las tablas, pero entonces sería necesario otro sistema de cifrado no basado en tablas por el mismo problema de antes.

Y fin, una hora entre leer la solicitud de patente y encontrar una manera sencilla y rápida de descifrarla, sin fuerza bruta, sin complicados cálculos… solo aplicándole un poco de la realidad en la que vivimos cada día los BOFHers y escribir este post.

Nokia (y Opera Mini) desencripta el tráfico https de sus teléfonos móviles

Un experto en seguridad de origen indio, Gaurang K Pandya, descubrió hace unos días que el navegador web que incluyen los dispositivos móviles de Nokia, envían todo el tráfico generado en los móviles a través de unos servidores proxy de Nokia, los cuales se encargan de comprimir la información entre el móvil e Internet para reducir el consumo de datos.

Esto no es nada nuevo, Opera Mini (en el que está basado el navegador web de Nokia) hace lo mismo, aunque, a diferencia de Nokia, no tiene reparos en mostrarte el funcionamiento de su navegador accediendo a servicios https como tu banco, tu correo, etc.

En ambos casos el funcionamiento consiste en que cuando accedes a través de protocolo seguro https a, por ejemplo, tu banco, estos navegadores web establecen una comunicación segura entre el dispositivo móvil y el servidor proxy de Nokia (o de la empresa Opera dependiendo cual de los dos navegadores uses) empleando un certificado seguro propio del servidor proxy, allí la información es desencriptada para posteriormente volverse a encriptar cuando el proxy conecta contra el banco.

Esto significa que toda la información que tú crees que viaja segura gracias al https, tus claves, tus datos bancarios, o tus emails si accedes a Gmail desde esos navegadores, está siendo convertida a texto normal, leible por cualquiera, durante su paso por los servidores proxy de Nokia… lo que solemos llamar un ataque de Man in the Middle.

Nokia ha admitido esta práctica, aunque dice que no nos preocupemos, que no almacenan esos datos y que el desencriptado se hace de manera segura, que han establecido medidas técnicas y organizativas para evitar el acceso a esta información privada… ¿Recordáis las medidas que tomó White Star para hacer del Titanic un buque insumergible?

En informática no es posible aseverar que un servicio es seguro con una certeza del 100%, incluido un protocolo seguro como https, que puede dejar de serlo por una mala implementación del software que lo maneja, como ha pasado recientemente con Windows Vista, 7, 2008, 2012 y RT.

Que una compañía haga un proceso de Man in the Middle a sus usuarios, ya sea Nokia (que encima no lo advertía de manera sencilla a sus usuarios), Opera o cualquier otra es una temeridad que puede dejar al descubierto no solo cuentas de correo a las que se ha accedido por webmail, sino información más sensible como datos bancarios, claves de operación en cuentas, etc. a nada que un fallo de seguridad permita a empleados de la compañía o terceros  escuchar el tráfico interno de la máquina… y ya hemos visto en otros posts de este blog la cantidad de técnicas que hay para hacerlo.

Si usáis cualquiera de estos dos navegadores web, que también están disponibles para otros dispositivos móviles como Android y Windows 7.5 y 8, tened mucho cuidado con los datos que le proporcionáis durante la navegación web, sobre todo en sitios seguros y con información sensible.

Más información, en inglés:

Nokia phone forcing traffic through proxy

Nokia’s MITM on HTTPS traffic from their phone

WiFi seguro: Comprometiendo claves WPA/WPA2 gracias a WPS sin mucho esfuerzo

A estas alturas de la vida resulta complicado encontrar una WiFi abierta o que use el viejo sistema de cifrado WEP, vulnerable a un sencillo ataque empleando herramientas como AirCrack.

Desde hace tiempo los routers WiFi que facilitan las operadoras de cable y ADSL al darte de alta usan otros sistemas más seguros como WPA y WPA2, que en algunos casos también son vulnerables al venir de serie con una clave predecible en base a cálculos que puedes hacer de manera automática con aplicaciones de Android como Router Keygen o Wifileaks.

Router Keygen

Sabes que usas un sistema de cifrado potente como WPA2 que es lo bastante seguro como para que cualquier persona que pase cerca de la señal no sea capaz de romperla fácilmente, también sabes que tu router wifi no está en la lista de aquellos cuya clave de serie es predecible (o bien la has cambiado)… pero es posible que tu clave siga sin ser segura por culpa de WPS, WiFi Protected Setup.

WPS es un mecanismo desarrollado por la Wi-Fi Alliance para facilitar la configuración sencilla de redes inalámbricas seguras, de los 4 métodos que admite, nos vamos a centrar en el que suele venir activado por defecto en los routers WiFi de las operadoras de ADSL y Cable, el del PIN.

Hoy se cumple un año del descubrimiento de una vulnerabilidad en este método que permite a un atacante obtener la clave WPA/WPA2 de un router WiFi empleando herramientas libres y unas pocas horas de tiempo.

El PIN de WPS consiste en un número de 8 cifras en la que la última cifra es un dígito de control del PIN, por lo que es conocido en cuanto tengamos las otras 7 cifras.

El modo en el que WPS responde a los diferentes paquetes de datos con el PIN que le son enviados, permite conocer si los primeros 4 dígitos son correctos, lo mismo sucede para los 3 dígitos siguientes más el dígito de control.

Esto hace que un ataque de fuerza bruta contra el router WiFi con el WPS activado sea solo cuestión de disponer de un poco de tiempo y paciencia.

Con 8 dígitos las posibles combinaciones numéricas que tiene el PIN son de 10⁸, es decir, 100.000.000 de posibilidades, “gracias” a este fallo de diseño solo necesitaremos conocer 10⁴ + 10³ combinaciones diferentes, que son 11.000 claves, un 0,011% del total de combinaciones posibles con 8 dígitos.

En algunos casos, el router WiFi dispone de algunas medidas como bloquear la dirección MAC de la máquina que hace demasiadas peticiones erróneas a WPS, que con un poco de maña  y paciencia podremos solventar empleando la herramienta Mac Changer para cambiar la dirección MAC de nuestra tarjeta de red y proseguir con el experimento.

Como ir probando a mano las combinaciones (y que interpretar las respuesta manualmente es un rollo), podemos automatizar el proceso empleando sobre una distribución Linux las herramientas Aircrack y Reaver WPS, por el camino de instalarlas en nuestro sistema, se nos pedirá que instalemos algunas librerías como libpcap.

El primer paso es activar un interfaz de monitorización con airmon-ng:

airmon-ng start wlan0

airmon

Con el interfaz mon0 activado, ejecutaremos airodump para localizar la BSSID de la WiFi que queremos comprobar:

airodump-ng mon0

airodump

Con el BSSID apuntado, ejecutaremos Reaver WPS:

reaver -i mon0 -a -b XX:XX:XX:XX:XX:7D -vv

Podemos detener en cualquier momento la ejecución de Reaver pulsando Ctrl+C, nos guardará la información que haya obtenido y podremos continuar la sesión en cualquier otro momento justo en el punto en el que nos quedamos, sin necesidad de volver a empezar desde cero.

La opción -a hace que reaver se configure del modo más óptimo para la prueba contra el router seleccionado.

Adicionalmente podemos especificar la MAC de nuestro equipo añadiéndola con la opción -m XX:XX:XX:XX:XX:XX, que deberá ser la misma MAC que hemos cambiado a nuestra tarjeta de red con Mac Changer

Si sabemos el PIN podemos probarlo directamente con la opción -p MIS8DIGITOS.

Si el router tiene activado el servicio WPS comenzarán las pruebas para descubrir el PIN, si el router no nos bloqueo por demasiados intentos fallidos, en un espacio de tiempo bastante breve (lo mínimo que he tardado hasta la fecha es poco más de 1h en algunas pruebas de concepto y cursos).

Pasado un tiempo obtendremos esto en pantalla:

wpa2

En este caso el proceso ha sido contra un router Netgear de ONO con clave WPA2.

La comprobación de que todo ha ido correcto es tan simple como conectarse al router de la prueba y facilitarle la clave que Reaver nos ha mostrado en pantalla y ver que podemos acceder a la red, internet, etc.

La solución es desactivar la opción de WPS (llamado QSS en algunos routers) y realizar de nuevo la comprobación para asegurarnos de que el router permite desactivarlo, ya que hay casos de dispositivos más antiguos de Linksys que permiten realizar esta prueba y obtener un resultado satisfactorio incluso con WPS desactivado (realmente no lo está desactivando aunque así aparezca en el interfaz web de nuestro router WiFi).

Si no podemos hacer efectivo el desactivado de WPS, la solución más segura es cambiar el router.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 116 seguidores

A %d blogueros les gusta esto: