HackStory: El libro a leer con la historia del hacking íbero

Si hay una periodista que ha seguido con interés, cariño y dedicación la historia de los hackers en España ha sido Mercè Molist. Durante más de 20 años ha sido común encontrarla en quedadas y eventos de hacking. Yo la conocí en el año 2007, cuando era una periodista de referencia de la sección de tecnología de El País. Un día decidió cambiar su orientación profesional y no dejar que todo lo que había visto, vivido y conocido se perdiera, así que decidió focalizar su tiempo y esfuerzos en la creación de HackStory,  un compendio de los inicios del hacking en este país, que poco a poco fue tomando cuerpo.

Figura 1: Mercè Molist con Kevin Mitnick

En el año 2012 nos contó que estaba buscando la forma de hacer un libro que recopilara, organizara y dejara listo para el futuro el trabajo, algo que como a muchos me encantó. Nosotros estábamos en aquel momento enfrascados también en el proyecto de publicar MicroHistorias, el libro que recoge las aventuras de los hackers de la historia de la informática, así que desde nos pareció una buena idea apoyarlo y desde Informática 64 apoyamos económicamente el proyecto con un porcentaje de las ventas de nuestros libros.

Figura 2: Contactar con Kevin Mitnick en MyPublicInbox

Este verano, coincidiendo con su regreso en los últimos tiempos a la primera línea de batalla de los medios de comunicación - que ahora desde las páginas de El Mundo está llevando al gran público temas de tan interés como el Ethical Hacking - ha publicado el libro de HackStory, con un montón de buenas historias.

Figura 2: Libro de HackStory

Yo soy fan de esas historias y los textos de HackStory y aunque muchas de las historias que se cuentan en el libro ya las he leído, estoy volviendo a leer muchas de ellas. Además, haber conocido a muchos de los hackers del libro con el tiempo, me hace disfrutarlo más. 

Cuando lees el prólogo de Zhodiac, con esa pasión que le pone, muchos no se imaginarán el pedazo de profesional y gran persona que hay detrás y todo lo que ha hecho en el mundo después de las aventuras que de él se cuentan. Disfruto mucho con la historia de los Apostols, de las que he disfrutado a lo grande cuando me las ha contado en persona Jordi Murgó, otro hacker que es más grande como persona que como hacker - y ya es decir -.

Figura 3: Los Apostols en 2013

También está la historia de Wiskey Kon Tekila y Estado+Porcino, con los que nosotros aprendimos cómo hacer los primeros cracks. Es genial haber conocido a muchos de ellos y saber que cuando yo aún comenzaba en seguridad informática, ellos ya estaban haciendo estas cosas.... y que seamos de la misma quinta.

También leer las aventuras de aquella época que me habían contado RoMaNSoFt, Dab y CRG en persona, es entrañable. Pero además podrás leer historias como la de Isla Tortuga, La Taberna de Van Hackez, la UnderCON, los inicios de la NoCONname, y un largo etcétera. Merece la pena la lectura, así que ponte con ello, y si puedes, apoya el proyecto para que tengamos una aplicación o continuación pronto.

Saludos Malignos!

La historia no contada de Estados Unidos - Bush y Obama: La era del terror. Un documental de Oliver Stone

Ayer, mientras terminaba mi largo día, me topé en La 2 con la emisión de un documental que me cautivó. Es parte de una serie de documentales que ha hecho el cineasta Oliver Stone sobre La Historia No Contada de Estados Unidos, de hecho es la parte número 10 de la serie, titulado "La era del Terror" y está centrado en los mandatos de George Bush (hijo) y Barack Obama, y cómo han gestionado el miedo del pueblo norte-americano para hacer cosas.

Figura 1: Documental "La Historia No Contada de Estados Unidos - La era del terror"

Al verlo, recordé cómo viví todo el proceso electoral de George Bush y Al Gore, con los problemas de papeletas en las máquinas de votación del último estado, el estado de Florida, donde gobernaba Jeff Bush, el hermano de George Bush, lo que fue uno de los actos más bananeros que se recuerdan del primer mundo. Recordé cómo viví el atentado del 11-S y cómo sentí esa empatía de la que habla Oliver Stone. Recuerdo cómo fue la declaración de la invasión a Irak y cómo fue el día que tiraron la estatua de Saddam Hussein y cómo lo vi por la televisión. Un montón de recuerdos cercanos de la vida en USA.

Figura 2: Portada de la revista Time en Diciembre de 2010 dedicada a Julian Assange

El documental trata temas todavía más reciente, como las filtraciones de WikiLeaks, la persecución por todo el mundo del sitio web. Yo recordé como eso me llevó a pensar en la creación de DUST RSS como forma de evitar algo similar.


Figura 3: Conferencia de Dust RSS dada en la RootedCON 2011
Recuerdo la reacción de Anonymous contra HBGary y el cambio de la empatía a la reprobación de algunas acciones de USA que acabaron estallando con las filtraciones de Edward Snowden sobre cómo la NSA acabó con el espíritu de Internet, que incluso se ha hecho parte de la cultura popular en el mundo entero.

Figura 4: Del "Yes, We Can" de Obama, al "Yes, We Scan" de la NSA

Habla también de la creación de las cárceles por todo el mundo como la de Guantánamo y la presencia militar en casi 200 países de Estados Unidos y de cómo allí algunas acciones han sido difíciles de justificar. Yo recuerdo la narración propia sobre el infierno que vivía Bradley Manning en una de sus cárceles, para al final acabar cumpliendo una condena ejemplar.

Figura 5: Campaña a favor de Bradley Manning

Creo que si no lo has visto, merece mucho la pena que le des un vistazo este fin de semana. En poco menos de una hora podrás repasar los últimos 15 años de la historia de Estados Unidos, centrada en el impacto de que ha tenido en todo el mundo esta "Política del Terror", que cataloga Oliver Stone en su documental.

Saludos Malignos!

Integración paso a paso de Latch en Laravel Framework, el entorno de desarrollo PHP para los artesanos de la web

Laravel, es un entorno de desarrollo de PHP en pleno auge. Destaca por su sencillez sin perder la potencia y funcionalidades de un buen framework. Además su curva de aprendizaje es muy asequible. Permite que los desarrolladores que comienza con él y sin demasiada experiencia en PHP, puedan aprenderlo muy fácilmente, y también que los que tengan más experiencia lo expriman de un modo avanzado. Para poder trabajar con Latch en él, he hecho una integración al igual que ya se hizo una de Latch para Django, así que en este artículo vamos a ver cómo integrar Latch en tu framework de Laravel.

Figura 1: Laravel, entorno de desarrollo de aplicaciones PHP

Instalación del paquete

Se debe usar un gestor de paquetes llamado Composer para instalar el paquete de "Latch para Laravel" disponible en su GitHub. El archivo composer.json (viene incluido en Laravel) permite definir qué paquetes de PHP se usarán en nuestro proyecto, así que se debe añadir la siguiente línea a este fichero en su require:

"faytzel/laravel-latch": "0.*"

Después se debe ejecutar en línea de comandos y a nivel de la raíz del proyecto composer update o composer.phar update (si es la primera vez que se ejecuta composer en nuestro proyecto se debe utilizar composer install o php composer.phar install) según el modo en que se instale composer en el sistema.

Una vez finalizado lo anterior se debe añadir app/config/app.php en la zona de los providers:

'Faytzel\LaravelLatch\LaravelLatchServiceProvider'

y en la zona de facades:

'Latch' => 'Faytzel\LaravelLatch\Facades\LaravelLatch',

Y por último ejecutar en en la raíz del proyecto php artisan config:publish faytzel/laravel-latch para añadir la configuración del paquete a app/config/packages/faytzel/laravel-latch.

Configuración del paquete

Si no se dispone ya de ella, es necesario crear una cuenta como desarrollador de Latch, igual que para poner Latch en WordPress o Latch en Windows. A partir de ahí, se debe crear una aplicación. Su nombre será el que le aparezca al usuario en la app de Latch en el smartphone. El ID de aplicación y el secreto serán necesarios durante la configuración de Laravel. Con esta información, ya solo falta empezar a escribir código.

Parear una cuenta de Latch

El método de PHP que realiza el pareado se llama Latch::pair() y permite parear al usuario de la web de Laravel con su cuenta de Latch. Esto ser realiza a través de un formulario e introduciendo el código de pareado que proporciona al usuario la aplicación de Latch en la app del móvil.

Ahora es necesario crear un controlador llamado LatchController que dispone de un método que servirá para parear la cuenta de un usuario de la web a la cuenta de Latch de su smartphone. Y para eso se utilizará Latch::pair(). Esto devolverá el identificador de Latch del usuario que se acaba de parear para poder administrar este pareado cuando sea necesario.

Figura 2: Latch para Laravel. Código de pareado.

Un detalle interesante es que es posible almacenar cifrado en la base de datos el identificador del usuario que devuelve la API de Latch. Así, por defecto Latch::pair() devuelve el identificador ya cifrado, aunque esto puede desactivarse (el segundo parámetro del método permite activarlo o desactivarlo).

Por otro lado, podría darse el caso, por ejemplo de que un usuario introduzca su código de pareado cuando éste ya ha expirado (a los 60 segundos los códigos de pareados expiran por motivos de seguridad). Ante estos casos el método Latch::pair() indicará que no se pudo parear. Latch::error() es un método que devuelve el mensaje de error que ha ocurrido (actualmente soporta inglés y español), o el código, si usamos Latch::errorCode() para tomar acciones determinadas según cada código de error. Al final el código quedaría algo similar e esto:

php


Class LatchController extends BaseController {
    
    public function pair()
    {
        // Comprobamos que venga el token desde el formulario
        if (Input::has('token'))
        {
            // Obtenemos el código de pareado del usuario
            $token = Input::token('token');
            // Intenta parear Latch con el código (token)
            if ($accountId = Latch::pair($token))
            {
                // Si consigue parear guardamos el identificador del usuario (cifrado) de Latch en nuestra base de datos
            }
            // Si ocurre algún error, mostramos al usuario un mensaje de error de una forma amigable
            else
            {
                echo Latch::error();
            }
        }
    }
}

Bloquear el acceso de login a cuentas de Latch bloqueadas

El siguiente paso tras la gestión del pareo, es bloquear el acceso de usuarios (en el formulario de login/autenticacion) que mantegan sus cuentas de Latch bloqueadas. Este es el código que debe introducirse en el controlador de login del proyecto que se esté desarrollando:

php

class LoginController extends BaseController {
    
    public function login()
    {
        // Datos del formulario enviados por el usuario
        $input = Input::all();
        // Reglas de validacion
        $rules = array(
            'email'       => 'required|email',
            'password' => 'required'
        );
        // validamos los datos del formulario de login
        $validator = Validator::make($input, $rules);
        if ($validator->passes())
        {
            // Credenciales para el inicio de sesion del usuario
            $credentials = array('email' => $input['email'], 'password' => $input['password']);
            // Establece si tenemos acceso para acceder a nuestra cuenta de usuario
            $locked = true;
            // Comprobamos si el usuario es valido pero sin loguearlo
            if (Auth::validate($credentials))
            {
                // Obtenemos el identificador del usuario de Latch de nuestra base de datos (con sql)
                $user          = User::where('email', '=', $input['email'])->first();
                $accountId = $user->latch_account_id;
                // Comprueba si Latch nos da acceso
                if (Latch::unlocked($accountId))
                {
                    $locked = false;
                }
            }
            // Si la cuenta del usuario no esta bloqueada
            if ( ! $locked)
            {
                // Autentica al usuario
                if (Auth::attempt($credentials))
                {
                    //
                }
            }
        }
    }
}

Latch::unlocked() indicará si el usuario no ha bloqueado nuestra aplicación desde su smartphone con Latch, y Latch::locked() haría justo lo contrario aunque no será necesario usarlo en esta ocasión. Como se ha mencionado anteriormente, el identificador se almacena cifrado en la cuenta. Latch::unlocked() hará todo el trabajo de forma transparente, por lo que no hay que preocuparse.

Desparear una cuenta de Latch

Ya solo falta poder desparear la cuenta de Latch del usuario de nuestra aplicación. Es simple:

php



class LatchController extends BaseController {
    
    public function pair()
    {
        // codigo ...
    }
    public function unpair()
    {
        // Obtenemos el identificador del usuario de Latch de nuestra base de datos
        $accountId = Auth::user()->latch_account_id;
        // Despareamos al usuario de Latch
        if (Latch::unpair($accountId))
        {
            // Eliminamos el identificador del usuario de Latch de nuestra base de datos
        }
        // Si hay algun error, se lo mostramos al usuario
        else
        {
            echo Latch::error();
        }
    }
}

Igual que con los otros métodos, por defecto Latch::unpair() descifra internamente el identificador.

Autor: José María Gómez

jmgomez0101@gmail.com

Un puesto de trabajo con buenas vistas... para todos

La cena de ponentes de la RootedCON suele ser un acto muy entretenido. Allí te juntas con un montón de buena gente que te aporta un montón de cosas. Entre copas, bromas, pullas, cotilleos y charlas varias, este año tuvimos la ocasión de disfrutar de una imagen bastante curiosa que nos sacó unas risas. A unos escasos 8 metros en linea recta de la puerta del restaurante donde íbamos a pasar de Kilobyte a Megabyte, había un edificio repleto de oficinas. En la planta baja, justo a nuestra altura a pie de calle había una oficina con un ventanal enorme y un trabajador dándole a la tecla.

Figura 1: El puesto de trabajo con el ventanal a pie de calle

Seguro que debía estar echando horas extras pues serían las 21:00 o 22:00 de la noche, y como se puede ver en la fotografía las pilas de papel que tiene tanto a la izquierda como a la derecha de los monitores no parecen de lo más halagüeñas. Además, el pobre estaba totalmente concentrado con sus quehaceres, controlando tres monitores a la vez, más una mesa de comunicaciones a la que estaba enchufado con sus cascos.

Figura 2: Pilas de documentos, tres monitores de control y una centralita

Tan concentrado estaba que no prestó atención a la centena de hackers que por allí danzaban con ganas de fiesta. Tanto fue así, que hasta nos pudimos acercar a la distancia de un metro para hacer fotos a gusto y leer los mensajes de los monitores. Yo he reducido la foto para preservar su intimidad, pero como podéis ver no hay persianas, ni protector de privacidad en los monitores.

Figura 3: Foto difuminada para mantener privacidad. ¿Qué fono de escritorio tiene?

No sé quién es el responsable de seguridad e esta empresa, pero desde luego, poner a una persona a trabajar con los monitores a la vista de todos los viandantes no parece ninguna buena idea. Lo de que aquella noche diera la casualidad de que se hiciera la cena de la RootedCON 2014 justo en frente, solo pudo ser el destino.... Eso sí, el puesto de trabajo tiene mucha luz y buenas vistas.

Saludos Malignos!

Riesgos de seguridad al cargar contenido externo en tu web

Desde hace algún tiempo, en todas las webs que auditamos con nuestro sistema de pentesting persistente Faast, una de las cosas que miramos es la lista de todas las fuentes de contenido externo que cargan en el sitio web. No solo lo que se carga en la página principal, sino lo que se carga en todas y cada una de las URLs de la web. Esto es importante, pues el ataque a los clientes de un sitio puede venir por un fallo en cualquiera de los servidores que están sirviendo código en la web que visualiza el cliente.

Los riesgos para un cliente pueden ser muchos, como el intento de distribución de malware o la inserción dentro de una Botnet JavaScript, pero también para el servidor, que al permitir que se cargue contenido se está abriendo la puerta a ataques de ClickJacking, Defacements, CSRF, etcétera, por lo que hay que tener mucho cuidado con qué contenido estás cargando en tu web.

El ataque de lo SEA a la web de la RSA Conference

Uno de los casos más recientes de ataque a una web mediante el compromiso de fuentes de contenido externo tuvo lugar en el defacement de la web de la RSA Conference, una de las conferencias de seguridad de más prestigio en el mundo. Para poder realizar el ataque, el grupo SEA (Syrian Electronic Army), aprovecho que se cargaba un fichero JavaScript desde un servidor web perteneciente a otro dominio. Este fichero se utilizaba para llevar las estadísticas de las visitas a la web y el grupo atacante busco la manera de que se cargara el fichero JavaScript que ellos querían. 

Figura 1: Esquema del ataque de SEA a la web de la RSA Conference

Para ello tenían que conseguir que el nombre de dominio del servidor remoto apuntara a una dirección IP controlada por ellos, por lo que revisaron en qué proveedor estaba registrado el dominio del servidor de las estadísticas e hicieron un ataque de phishing a los empleados del registrador - que buscaron por Linkedin - para robar credenciales de acceso a la gestión de los dominios.

Figura 2: Defacement mostrado por el fichero JavaScript malicioso cargado remotamente

Con una de esas identidades robadas fueron capaces de gestionar el DNS del dominio al que pertenecía el servidor de las estadísticas y hacer que el nombre del servidor que cargaba el fichero JavaScript en la web de la RSA Conference apuntara a un servidor web controlado por ellos, desde el que cargaron un fichero JavaScript distinto que mostraba el mensaje que ya se ha hecho famoso que puedes ver en la Figura 2.

El Malvertising o la distribución de malware por redes de publicidad

El termino de Malvertising viene de Malicious Advertising, o lo que es lo mismo, contratar con una empresa de publicidad una campaña en la que puedes meter contenido Flash o JavaScript. Esto ha demostrado ser una forma perfecta para para los amigos del Fraude Online de distribuir contenido JavaScript malicioso a través de los propios ficheros JavaScript de la red de publicidad que muchos sitios webs utilizan para ganar dinero. 

Figura 3: Esquema de Malvertising utilizado a través de Yahoo! Ad Network

Esto ha sucedido muchas veces en el paso, y la empresa FOX IT - donde trabajan algunos de los mejores investigadores de e-crime españoles - reportaron este año un caso de malvertising utilizando la red de Ads de Yahoo! para distribuir bots de diferentes tipos a través de un Kit de Exploits.

El Hot-linking de imágenes

No podía terminar esta recolección de ejemplos de porque puede ser malo utilizar contenido externo en tu web, sin hablar del Hot Linking. Cargar una imagen - por ejemplo para decorar un artículo en la página de noticias de la compañía o en el blog corporativo - puede terminar con un cambio de imagen en el servidor original que afecte a la reputación del sitio que incrusta la imagen.

Figura 4: Un mensaje típico de una web enfadada por el Hot-Linking

Este es un error muy de novato, y que en tiempos en los que el ancho de banda era más costoso para los servidores web estaba muy mal visto. Si tienes un blog corporativo evita este tipo de acciones para evitar problemas.

La privacidad de los usuarios

Cuando se carga contenido externo de una web remota, el uso de ese fichero JavaScript podría llevar a que se accediera a mucha información de la navegación de los usuarios. Es utilizado habitualmente por servicios de estadísticas, pero también mucho proveedores de tecnología hacen un seguimiento excesivo de la navegación de los usuarios.

Figura 5: Cómo Facebook espía la navegación de sus usuarios

Facebook está siendo investigado por la Unión Europea por espiar la navegación de los usuarios y Google ya fue demandado en Estados Unidos por espiar a sus usuarios. Ponerles sus librerías es abrir esa puerta de acceso a datos de tus clientes.

La carga de contenido externo hace menos segura tu web

Al final, cuando en una web se carga contenido remoto se está confiando en la seguridad de ese dominio, y no siempre es lo más adecuado, ya que los clientes del sitio web principal podrían verse atacados por un fallo en la seguridad de la gestión de cualquiera de los servidores remotos.

Por eso, cuando revisamos una web hay que mirar qué contenido se carga, y por qué se carga ese contenido. Al final, en la mayoría de los casos un fichero JavaScript o CSS podría cargarse desde el propio servidor y no dejar que un cambio en ese fichero JavaScript pudiera generar un fallo nada deseable, o una caída de servicio en alguno de esos servidores.

Figura 6: Contenido externo cargado en una web, visto con el inspector de contenido de Google Chrome

A lo largo de este tiempo hemos visto sitios que cargan ficheros JavaScript de efectos para el interfaz de usuario desde repositorios de código controlados por desarrolladores que ni son conocidos. Si ese desarrollador cierra, o lo que es peor, se vuelve malicioso y vende ese JavaScript a la distribución de malware, todos los sitios que lo incluyan estarán atacando a todos sus clientes.

Si es un fichero JavaScript para conseguir una determinada función en el interfaz de usuario o fichero CSS de una plantilla de la web, lo más sencillo sería copiar esos ficheros al servidor web principal y reducir al máximo el número de problemas que se deben afrontar.

Contenido externo y rendimiento

Una de las cosas que pueden llevar a alguien a cargar contenido desde servidores remotos es el límite de conexiones concurrentes paralelas que se pueden hacer desde un navegador de Internet a un servidor web. Esto no debería de ser un problema. En el caso de los límites del servidor web, eres tú el que lo controlas y configuras, así que haz tunning de tu servidor web y listo.

Figura 7: Tabla de conexiones concurrentes por hostname en cada navegador

En el caso del navegador del cliente sí que hay límites, pero los límites son por hostname, y como puede verse, estas son muchas. Si el rendimiento es un issue y necesitas paralelizar, lo mejor es que optimices el contenido que vas a cargar al cliente, uses ficheros JavaScript comprimidos y en bundle, y si son muchos los archivos que necesitas, pues que montes tu propia CDN con distintos hostnames o uses una CDN de confianza como servicio, pero cargar contenido de "por ahí" tiene sus riegos, así que evita todos los que puedas.

Saludos Malignos!

Descuentos trampa en "Los 14 Días Locos de Conforama" descubiertos con Archive.org "The Wayback Machine"

¿Quién no ha visto una oferta en Internet y se ha dejado cautivar por los colores llamativos? ¿Quién no ha sentido la emoción de estar frente a una ganga cuando se puede ver que el precio original ha sido reducido en un 30%? ¿Quién ha dicho un 30%, si hasta puedes encontrar 50% y 70%? ¡El día sin IVA!, el MegaOfertón, la Super-Mega-Oferta-Definitiva. Somos seres consumistas que nos dejamos atraer por este tipo de campañas que nos llevan hipnóticos a comprar.

Pero... ¿realmente estamos seguros de que es una oferta o simplemente nos están haciendo creer que es una oferta? Pues esta es una historia real que me ha contado un lector del blog y que me ha hecho mucha gracia por la desfachatez de la misma. Es una una oferta de Los 14 Días Locos de Conforama, que no es tan oferta y que ha sido pillada por uno de los sistemas que a veces usamos para hackear sistemas: Archive.org

Figura 1: Según Conforama están derritiendo los precios

El sitio de The Wayback Machine es como la hemeroteca de las páginas web. En ese sitio puedes ver cómo ha ido cambiando una página web a lo largo del tiempo, puedes mover el dial de la historia y ver cómo se podría ver una URL hace seis meses, un año o hasta 10 años si lleva mucho tiempo en Internet.

Figura 2: En Archive.org puedes ver el pasado de cualquier URL

Así que, nuestro amigo Alex, vio un ofertón en la tienda de Conforoma en el que se podía ver que un mueble contaba con un 50% de descuento sobre el precio original del producto. Una oferta sin duda que como tal, debe ser solo por tiempo limitado, final de existencias, o cualquier otro motivo que lo justifique como estos 14 Días Locos de Conforama.

Figura 3: El precio actual, con un 50% de descuento. Un ofertón.

Nuestro amigo, conocedor de otros sitios web que a veces no hacen tan buenas ofertas como propone y como además conoce las maravillas de Archive.org, decidió que podría ser una buena idea el comprobar cómo había ido variando el precio de dicho producto. Puso la URL del producto en The Wayback Machine y movió el dial de la historia hasta, por ejemplo, el 2 de Enero de este año, y esto es lo que se puede ver.

Como veis, el precio final no ha variado un ápice en estos 8 meses, - y tampoco dentro de estos 14 Días Locos de Conforama - pero lo mejor de todo es que sí, que ¡el descuento ha aumentado! Ha pasado de un simple 33% a un maravilloso 50%... 

Figura 4: En Enero de 2014 la oferta era menor porque el mueble costaba menos.

¿Cómo es esto posible? Pues por la inflación de las cosas - y eso que el gobierno en España dice que los precios están bajando. Ni mucho menos, el precio de este mueble, como el de los buenos vinos ha subido durante estos 14 Días Locos así que en lugar de derretirse los precios crecen solitos. Este mueble se ha debido convertir en un clásico. Por suerte para el comprador, Conforama ha decidido subir el descuento durante estos 14 Días Locos y mantener el mismo precio. Ahí la oferta.

Lo cierto es que este truco lo puedes hacer con muchas tiendas online, y si haces como Alex y sacas una copia de cada URL con el servicio de web firmada de eGarante, tal vez puedas utilizar esta información para denunciar públicamente alguna falsa campaña de promoción como esta.

Saludos Malignos!

Evernote no quiere hacer nada: ¡Cuida tus publicaciones!

La historia que os voy a narrar ahora tuvo lugar hace más de dos meses con Evernote, pero por la naturaleza de la misma no he podido ni querido publicarla antes. Ahora he sacado un poco de tiempo para contaros con detalle toda la historia, porque sigo indignado con el soporte y creo que es ya demasiado tiempo sin hacer nada. Es una aventura larga, así que más vale que te sientes cómodo en la silla, prepares el cafe y estés tranquilo los próximos minutos. No es artículo con mucha sesera técnica, pero sí que es de longitud, así que ten paciencia.

Evernote y la indexación de las carpetas públicas

Son muchos lo usuarios que publican cosas en abierto en sus cuentas de Evernote. Hasta aquí no hay demasiada novedad. Eso sí, hay que tener cuidado con que se publique una cosa privada cómo pública, porque entonces viene todo el lío. En un artículo en el que hablaba de las posibles fugas de información por las revisiones de artículos con WordPress usaba Evernote como un posible punto de falla para que algo que debería ser privado acabara indexado en la base de datos de Google.

Figura 1: Casi 40.000 documentos públicos en Evernote

Digamos que en una de esas búsquedas, dentro los miles y miles de cosas que hay en abierto di en el Índice de Google con un documento de Evernote en el que un usuario había guardado todas sus identidades [usuarios y passwords] de servicios online. Esto se podía ver en los resultados que muestra Google, pero al hacer clic en el enlace, el resultado es que el usuario había des-publicado de Evernote es documento, y no se podía acceder a ello.

Figura 2: El documento ya no estaba publicado en Evernote

Por supuesto, lo siguiente que había que probar era si ese documento de Evernote estaba disponible en la Caché de Google, pero al intentarlo, no había nada disponible. Por eso de cubrir todas las posibilidades mire en Bing y hasta en Archive.org, pero no. El documento no estaba guardado en ninguno de esos sitios. ¿Eso quiere decir que están a salvo las credenciales que publicó ese usuario? La respuesta es NO.

La Caché de Google y el Índice de Google

Aún mucha gente no entiende las diferencias entre el Índice de Google y la Caché de Google. Digamos que la Caché de Google es un almacenamiento de documentos que han sido visitados por el bot mientras que el Índice de Google es una base de datos en la que el bot guarda la información necesario para poder hacer las búsquedas.

Cuando alguien busca en Google, los resultados se traen directamente desde la base de datos que tiene indexada el motor. En ella no están todos los resultados de Internet, ni mucho menos, y tampoco todos los resultados de un sitio que Google esté analizando. Esto os lo expliqué en el artículo en el que hablaba del Índice principal y el Índice secudario de Google. 

La Caché de Google es, por otro lado, una especia de Archive.org temporal, pero solo para algunos de los documentos que Google indexa. No tienen porque estar todos los indexados, pero sí que no va a estar ningún documento que no haya sido crawleado y puesto en el índice en algún momento. Algunas veces, es posible ver un documento que ya no existe y que aún está en la Caché de Google.

Dicho esto, al final cuando una página web, como por ejemplo un documento público de Evernote es analizado por Google, la información que en él se contiene puede quedar en múltiples sitios, siendo uno de ellos el Índice de Google, que no tiene nada que ver con la caché.

Figura 3: Aunque el documento se quite de Evernote, ha sido copiado en muchos sitios

Por supuesto, en el Índice de Google no está la copia del documento, sino los datos filtrados para que los usuarios puedan encontrar la información. No está, por ejemplo el CSS del documento, pero sí las cadenas de texto que están contenidas dentro de la web analizada. En el caso de un documento de Evernote se encuentran, por ejemplo, las cadenas que el usuario haya escrito en él, como en este caso, los usuarios y contraseñas de sitios web.

Extraer los datos del Índice de Google

Extraer todos los datos del Índice de Google no es trivial, pero tampoco es rocket science que dicen los anglosajones. En cada petición vas a obtener solo un par de líneas de resultado, por lo que si el documento tienen muchas líneas va a ser una ardua tarea extraer todas. Además, Google no va a guardar absolutamente todo el texto de una web. En el procesado de textos para búsquedas se aplican algoritmos que extraen las partes importantes y quitan el resto.

Es decir, ni hay garantía de que el Índice de Google tenga toda la información, ni de que puedas extraer todo con búsquedas, pero ... seguro que puedes sacar un buen trozo. Y eso es lo que hice. Primero manualmente, y luego con una herramienta que hemos hecho en Eleven Paths y que en cuanto esté depurada y pase por QA os pondremos a disposición pública.

Al final, lo que hice fue probar búsquedas con todas las palabras que habían salido una vez, y luego con un pequeño diccionario, todas restringidas a la URL, para poder sacar, haciendo un poco de Hacking con Buscadores, el máximo posible del índice. Y creedme que salió una cantidad bastante grande de datos. 

La protección contra el Indexado y la Caché en Google

Por supuesto, Google ofrece a los dueños de los sitios web herramientas para evitar tanto la indexación como el cacheo de contenidos. Herramientas distintas para cada opción. En primer lugar, para evitar la indexación de URLs de forma preventiva se puede usar la tag HTML NoIndex, y el HTTP Header X-Robots-Tag "NoIndex". Eso evitaría que cualquier URL que se encuentre - sea como sea - acabe en el índice.

En el caso de Evernote, evitar la indexación de contenidos no tiene sentido, ya que hay muchos usuarios que utilizan Evernote como su punto de publicación de cosas, como si fuera un blog, una web o un Tumblr. Si lo hacen público es porque les interesa que sea público y visitado por otros, así que, el que los visitantes encuentren sus contenidos vía un buscador como Google es una buena cosa.

Ahora bien, si en un determinado momento el administrador de un sitio quiere evitar la indexación de algunas URLs, puede hacer uso de los famosos robots.txt - que solo evita que se indexe el contenido y no la URL si es localizada por otros medios -. Para borrar cualquier rastro de un documento en el Índice de Google, incluida la URL, el dueño del dominio, siempre podrá eliminar cualquier URL usando las Herramientas del Webmaster. Solo si eres el dueño del dominio o si se ve afectada tu privacidad y lo solicitas tú. Y aquí viene todo el problema.

El reporte al equipo de soporte de Evernote

Dicho todo lo anterior, al ver que el usuario había des-publicado el contenido, intenté avisarle de que aún era posible extraer la información del índice. Busqué las direcciones de correo que pude del usuario y le puse un par de correos, que no sé si llegaron, porque no me contestó y nada pasó. Lo cierto es que no conseguí localizarle.

Después de eso, me puse en contacto con un viejo amigo del equipo de seguridad de Google, que me volvió a confirmar lo que ya sabía. La URL del Índice de Google solo la puede sacar el dueño de la URL, es decir, el administrador el dominio del que cuelga la URL: En este caso Evernote. Esta es la línea temporal de los acontecimientos.

1 y 2 de Junio: Primer Intento

Con estas me puse en contacto con Evernote y le conté todo el caso. Le pasé la información, el correo que había enviado al usuario, los datos que estaban en el Índice de Google, y le expliqué que solo debían eliminar la URL con las Herramientas del Webmaster de Google y listo. Este fue el correo que les envié.

Figura 4: Reporte a Evernote con el correo enviado al usuario

Por supuesto, como era de esperar en la primera contestación pasaron de leerse en detalle mi correo y me contestaron que todo estaba OK, que ya el usuario había des-publicado el contenido de Evernote. FAIL 1.

Figura 5: Evernote contesta que el usuario ya ha des-publicado el contenido

Me armé de paciencia y le expliqué que el problema es precisamente ese, que el usuario ha quitado el contenido de la web de Evernote, pero que es Evernote quien tiene que quitar el contenido del Índice de Google. 

Figura 6: Segundo correo a soporte de Evernote insistiendo sobre el problema

10 de Junio: Segundo Intento

Tras una semana de paciencia sin dar ninguna contestación, el día 10 de Junio, vuelvo a responder al correo electrónico para insistirles en que son ellos los que deben eliminar el contenido. Como no me han contestado les digo que entiendo que si no me contestan más es que pasan del tema y que lo dan por zanjado.

Figura 7: Insisto el día 10 de Junio en un tercer correo

Pero me contestan. De nuevo, pasan de mover un dedo y de leerse en detalle mi correo. Me dicen que es decisión del usuario contactar con Google para que elimine la URL de la Caché. Dos errores gordos impropios de una empresa que quiere ser alguien en el mundo de Internet. FAIL 2.

- Error 1: No está en la caché, está en el índice.
- Error 2: El usuario no puede pedir a Google que quite la URL, solo Evernote.

En mi cuarto mensaje de correo, el quinto en total intentando resolver este problema, les explico la diferencia entre la Caché y el Índice de Google, y les transmito - de nuevo - que el único que puede quitar el contenido del Índice de Google cuando la URL cuelga del domino Evernote.com es el administrador de Evernote.com con las Herramientas del Webmaster de Google.

Figura 8: Explicación a Evernote por enésima vez que el contenido está en el Índice Google

Para enfatizar aún más por qué es importante que hagan esto les explico que si el usuario ha querido quitar el contenido de Evernote, es porque no quiere que el contenido sea público y que ellos pueden eliminar los datos del índice fácilmente. El usuario puede tener la "falsa sensación de seguridad" de que el contenido ya no es público.

Figura 9: Último intento de enfatizar el asunto

Tras este mensaje, parece que el usar mayúsculas les hace intentar entender qué es lo que estoy explicándoles. Total, solo han tardado 10 días en comprender qué es lo que les estaba reportando. A lo que entonces, contestan que su política es no hacer nada, y se quedan más anchos que largo.

Figura 10: Lo hemos entendido, pero no vamos a hacer nada.

12, 18 y 19 de Junio: Tercer contacto

Yo ya no les contesté a ese correo, y el día 12 de Junio me volvieron a escribir para ver si tenía algo más que decir. Yo les contesté que no, que ya estaba esperando a que se borrase de forma natural el contenido del Índice de Google para publicar este artículo - con la esperanza de que se eliminase pronto -.

Figura 11: Último correo mío al respecto de su decisión de política

Tras ese correo, tardan una semana otra vez, pero parece que piensan que "a lo mejor" todo lo que yo estoy diciéndoles es bueno para ese usuario - que ha cometido un error gordo y que es usuario de Evernote - preguntarle si desea eliminar el contenido del Índice de Google Algo que parece razonable.

Figura 12: Parece que van a poner algo de sentido común al caso.

El día 19 de Junio yo les contesto que me parece una aproximación a la solución del problema mucho más adecuada que la primera respuesta. Creo que esto lo tenían que haber hecho el día 1 de Junio, y no casi veinte días después.

Figura 13: Último correo intercambiado

¿Se eliminó a día de hoy el contenido?

Yo he ido siguiendo el estado de esa URL en el Índice de Google, y os juro que parece cuasi inmortal. Han pasado más de dos meses desde que la descubrí y ayer la firmé digitalmente en las búsquedas con eGarante, por si en el futuro me dicen que la cosa fue rápida.

La política de Evernote es no hacer nada y nada van a hacer. Algo que yo no comparto, porque si ya saben que el usuario ha querido quitar esa publicación, él no espera que esté eso en el Índice de Google. Ellos no lo avisan en ningún momento en su web. Nunca dice la web de Evernote que los datos permanecerán en Google tiempo después de su des-publicación. 

Ahora, tras este caso Evernote lo sabe, así que creo que deberían avisar a los usuarios o hacer algo al respecto. Fuera del canal de soporte les he transmitido mi malestar con su comportamiento en este caso concreto, y creo que debería ser cuasi ipso-facto el que si un contenido de una web de un servicio como Evernote deja de estar publicado se elimine del Índice de Google o que al menos las webs tengan un sitio para pedir este borrado avisando de la situación. No solo en Evernote, sino en cualquier otra web que haga algo similar.

Puede ser incluso que el usuario no conteste a día de hoy porque ya le robaran las cuentas antes de que yo me pusiera en contacto con él explicándole el problema. Si el usuario se diese cuenta de esto, podría forzar al borrado del contenido del índice de Google de esta forma: Solicitar borrado de contenido del índice de Google aunque el sitio no sea tuyo.

Por supuesto, entiendo que el error - seguramente por desconocimiento de lo que estaba haciendo - lo comete el usuario, pero en ningún caso Evernote ha mostrado sensibilidad por los datos de su usuario. Por supuesto, tirarse 19 días intentando explicarles el problema tampoco fue nada divertido, y espero que si más investigadores les reportan problemas presten más atención a los reportes.

Saludos Malignos!

Extracción de claves GnuPG con el poder de tu mano (Jedi)

Tenía pendiente desde que salió publicado, la lectura de este paper sobre criptografía, firmado en la Universidad de Tel Aviv. El título ya de por sí había generado mucho buzz en los medios, y había leído algunas cosas, pero necesitaba algo de tiempo para entender qué es lo que habían hecho y cuáles son las posibilidades de este trabajo ya que tenía en mente trabajos similares anteriores. El documento, que puedes descargar en PDF desde la siguiente URL, se llama "Get Your Hands Off My Laptop: Physical Side-Channel Key-Extraction Attacks on PCs".

Figura 1: Get Your Hands Off My Laptop

Una vez leído, parece que lo que han hecho ha sido una implementación de los famosos ataques de Criptoanálisis Acústico, a un escenario en el que el side-channel no es el sonido que se genera desde el microprocesador, sino las vibraciones que se generan en los elementos físicos cada una de las diferentes operaciones que realiza el microprocesador. A ver si consigo explicarlo.

Los ataques Tempest

Los ataques Tempest se basan en medir canales paralelos para poder extraer la información original que los genera. Se hicieron famosos por los ataques a monitores CRT donde se medían la frecuencia y se podía ver la pantalla de una determinada persona, pero el número de ataques han ido creciendo. Aquí os dejo un ejemplo de cómo se podría utilizar para saber a quién está votando una persona en un sistema de voto electrónico de Holanda.


Figura 2: Ataque Tempest al sistema de voto electrónico Holandés
Hoy en día tenemos ataques que se han hecho muy populares, como el que conseguía grabar las pulsaciones de teclado midiendo con una luz en la tapa de la pantalla las vibraciones al pulsar las teclas, los keloggers hechos con los acelerómetros de los smartphones, etcétera. 

Yo, reconozco que tuve la ocasión de aprender mucho sobre Tempest en el evento Asegúr@IT III que hicimos en Bilbao, donde Pablo Garaitzar a.k.a. "Txipi" de la Universidad de Deusto, dio una de las charlas más entretenidas y educativas que recuerdo. El tema fue Tempest: Mitos y Realidades y puedes conseguir el audio de la sesión y las diapositivas, además de poder ver el vídeo que tengo subido a mi canal Youtube desde hace tiempo. Aquí os lo dejo.


Figura 3: Tempest - Mitos y Realidades

En esta charla, hacia la parte final, Txipi habla del Criptoanálisis Acústico a partir de los sonidos que genera el microprocesador de un equipo cuando está haciendo una determinada operación. Es decir, la idea es que cuando un microprocesador hace un HTL o un NOP o un ADD, genera un señal acústica distinta que puede ser grabada con un micrófono.

El criptoanálisis Acústico

Figura 4: Criptoanálisis Acústico

En el año 2004, Adi Shamir - la S de RSA - y Eran Tromer demostraron que era posible reconocer el algoritmo de cifrado y descifrado de un dato con solo grabar sus sonidos, lo que abría el camino a los ataques criptográficos vía sonido. Este mismo ataque culminó el año pasado con el paper en el que, haciendo un ataque criptográfico al algoritmo de GnuPG se podía saber qué clave privada de cifrado se estaba utilizando para cifrar una cadena.

Figura 5: Sonido de cifrado con clave privado en GnuPG. Puedes descargar el audio.

Este trabajo del año pasado, titulado "RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis", recibió este año en la Black Hat USA 2014 el Pwnie Award a la Investigación más innovadora. En él, es en el que se ha basado este nuevo paper del que va el artículo de hoy.

Side-Channel usando el contacto físico

Eran Tromer ha continuado con este trabajo, y lo que ha hecho ha sido cambiar el canal paralelo. En lugar de utilizar un micrófono para grabar los sonidos y hacer un procesado de señal de audio, lo que hace ahora es extraer esas diferencias en el espectro de cada una de las operaciones del microprocesador, pero usando las vibraciones en los dispositivos físicos conectados.

Figura 6: Diferentes señales generadas por las diferentes operaciones

Para ello, con tener cualquier contacto físico con el equipo se podría obtener una señal que recoja el estado de todas las operaciones de un microprocesador, permitiendo saber qué algoritmos está ejecutando en cada instante.

Figura 7: Captura de la señal por vibraciones en el cable de red

Por supuesto, lo que más ha llamado la atención es que la grabación de la señal se haga tocando el equipo, la mesa, o el cable de red donde está conectado el sistema informático, haciendo que proteger la información sea cada vez más complicado en muchos entornos.

Figura 8: Captura de la señal física con el toque de la mano

Espero que con este resumen os haya quedado más claro, que no hay nada mejor para un domingo que verse una charla sobre Tempest, leerse un libro de cifrado RSA para saber de qué va esto del criptoanálisis, y degustar un paper sobre extracción de claves de cifrado usando criptoanálisis de vibraciones físicas. 

Saludos Malignos!