Mostrando entradas con la etiqueta Criptografía. Mostrar todas las entradas
Mostrando entradas con la etiqueta Criptografía. Mostrar todas las entradas

lunes, septiembre 29, 2014

Un misterio criptográfico en la Universidad

Siempre estamos expuestos a cantidades ingentes de información, la mayoría de las veces visual, y sobre todo escrita, aunque habitualmente paseamos por el mundo sin prestarle demasiada atención. Pero, si nos tomamos cuidado para intentar fijarnos en los detalles, a veces nos podemos llevar más de una sorpresa. La siguiente historia es un claro ejemplo de esto, ya que por prestar atención al entorno, acabé involucrado en un misterio de criptografía.

Figura 1: Un misterio criptográfico en la universidad 

Un encuentro fortuito en la Universidad

A principios de este año, caminando por los pasillos de una facultad de una universidad pública conocida tuve la “suerte” de encontrar esto tirado en el suelo, documento que me he tomado la libertad de borrar –de forma muy amateur – algunos segmentos de la hoja para no implicar a las personas de la lista.

A primera vista es una página que podría pasar desapercibida por ser una hoja con los resultados y calificaciones de algún trabajo o examen de la universidad, sobre todo por la estructura y más aún al encontrarse debajo de uno de los tablones que se usan a tal fin. La sorpresa viene cuando te paras a intentar leer detenidamente algo de lo que está escrito en ella, ya que aquello es totalmente ilegible a simple vista.

Figura 2: El extraño documento tirado en la Universidad

Cualquier otro en mi lugar hubiera dejado el papel donde estaba o, al recogerlo y verlo, lo habría tirado a la basura. Pero a mí me picó la curiosidad, así que me lo guardé para “analizarlo” más tarde en casa. El papel me recordó a los problemas y retos a los que jugaba con mi abuelo cuando era más pequeño. Al fin y al cabo, detrás del texto estaba la atracción inherente de todo reto.

Ya que había decidido que iba a jugar con esto, antes de abandonar el lugar de los hechos tuve la precaución de revisar sin éxito el suelo y otros tablones adyacentes para ver si encontraba más especímenes de este tipo, pero no hubo ninguna suerte. Este ejemplar era único en esa zona. Habría que intentar sacar todo lo necesario de allí.

Primeras impresiones sobre el misterio

Una vez en casa, confirmé mi idea de que se trataba de algún tipo de lista de clase: arriba podemos ver el encabezado con los datos de la asignatura y el curso en cuestión, así como el escudo de la Universidad (bueno, lo podríais ver si no lo hubiera eliminado de la imagen). Más abajo encontramos tres columnas, con lo que, a priori, parecen ser nombres y apellidos, DNIs y notas numéricas. El hecho de que el listado central estuviera ordenado alfabéticamente (aunque sin ningún sentido en castellano) reforzaba esta idea. Pero por qué estaba codificado era el misterio.

Como no era el primer documento cifrado con el que me topaba, decidí intentar descifrarlo. No estaba seguro de si un escáner OCR, incluso aplicado al documento original, funcionaría correctamente para pasar los caracteres al equipo y lanzarle baterías de análisis automático, así que primero decidí tratarlo analógicamente, al estilo de mi abuelo con sus acertijos.

Lo primero que se me ocurrió fue someterlo a un análisis de frecuencia para ver qué letras o grupo de letras tenían mayor número de apariciones, pero deseché la idea por dos motivos: primero, que eso solo me serviría con los caracteres alfabéticos, no tendría utilidad ni para números ni para el resto de caracteres como puntos o comas. Y segundo y más importante, me parecía un esfuerzo importante como para hacerlo a mano.

Así que le saqué una foto a la página y la compartí con un grupo de amigos a los que les gustan estas cosas y que a veces tienen muy buenas ideas. Introduje el tema preguntando de qué tenía pinta la hoja, y todos coincidieron en decir que se trataba de un listado de notas de la Universidad (les adelanté que no creía que se tratase de las notas de una asignatura de criptografía, aunque como idea no estaba mal). Algunos sugirieron la posibilidad de que estuviese escrito en otro idioma, aunque seguro que no era así, pues los caracteres pertenecen al alfabeto latino. Les pedí ayuda para resolver el primer reto: decodificar la hoja. Si lo conseguíamos estaríamos un paso más cerca de conocer el resto de detalles al respecto.

Figura 3: Ideas sobre la decodificación del listado

Tras un ratito de debate (en el que surgió la útil pero aburrida idea de usar Haskell para descifrarlo), llegamos a la conclusión de que estaba codificado usando una variación del clásico Cifrado César, en la que en lugar de desplazar cada carácter (ojo, no solo las letras) tres posiciones a la derecha el desplazamiento era de una sola posición. El hecho de que se mantuviese el orden alfabético era una pista importante para ello.

Figura 4: El debate en WhatsApp fue dando ideas

Una vez comprobado que se trataba de ese cifrado (traduciendo algunos segmentos y viendo que en efecto se corresponden con términos en castellano: González, Gómez… Y en efecto la cadena EOJ coincide con las siglas DNI) el siguiente paso era averiguar cómo y por qué. Es decir, la criminalística y la criminología del hecho.

Es un detalle curioso el hecho de que también tanto los números (como se puede comprobar en el encabezado de la hoja, donde se lee Dvstp!Bdbel n jdp!3124.25Curso académico 2013,14) como los signos de puntuación estuviesen desplazados sugiere que el cambio se ha hecho sobre una tabla de caracteres, bien en un driver o bien en una tipografía diseñada ad hoc.

Investigación de campo en la Universidad

Para ello el primer paso era analizar en profundidad el contenido de la lista. En efecto se trata de una lista de clase, con los alumnos matriculados en una determinada asignatura ordenados según sus apellidos alfabéticamente. En la primera columna aparecen los DNIs correspondientes, mientras que la última no refleja ni las calificaciones ni los nombres de los trabajos. En su lugar lo que aparece son los usuarios virtuales de cada alumno de la universidad.

Esta información, aunque es fácil de conseguir (pues el algoritmo que se usa para generarlos es unir las tres primeras letras del nombre y ambos apellidos; en caso de conflicto con otro usuario ya existente se añade un contador numérico al final al usuario virtual), se supone privada, de forma que solo tienen acceso a ella el propio usuario y los servicios informáticos y de administración de la universidad (según me contestaron cuando pregunté, hay veces en que ni siquiera los propios profesores tienen acceso a esa información). Por tanto y teóricamente no es algo accesible a todo el mundo (lo que supone, por tanto, una violación – aunque cifrada – de la intimidad de la gente, en especial que la persona responsable dejase el papel tirado en medio del pasillo).

Bien, dicho esto, ese hecho despertó mucho (más) mi curiosidad: si se trata de una información ya de por sí restringida o clasificada, ¿qué sentido tiene codificarla de nuevo? ¿Quién esconde una sala dentro de una base ya secreta? ¿Y a qué fin? Además, para más INRI, usando un cifrado técnicamente tan débil (visiblemente puede que asuste). Por más que buscaba, no le veía sentido.

Cabían dos opciones:
- Que fuese algo involuntario: que se hubiese producido un error en la impresión.
- Que fuese algo intencionado: bien como reto de alguien o para ocultar información.
Investigación de campo en Internet

Investigué por Internet acerca de fallos que ocasionasen el cambio de caracteres en la impresión, pero no encontré nada al respecto. Y la verdad es que me parecía algo bastante extraño como para que no hubiese bibliografía al respecto. También podía tratarse de un virus informático o que la universidad usase un sistema de cifrado digital que deja mucho que desear. En el segundo caso, había tres enigmas que resolver: quién, cómo y por qué.

Dado que, tras mi infructuosa búsqueda por la red, me pareció más probable (e interesante por supuesto) la segunda opción, decidí diseñar hipótesis para la misma.

En cuanto al quién, la cosa era bastante evidente: alguien con acceso a esa información (me parecía muy improbable que alguien hubiese diseñado un ataque dirigido para conseguir tal información, máxime teniendo en cuenta que las contraseña no aparecen – por suerte – en la página). Esto reduce bastante la lista a profesores y miembros de administración (suponiendo que ningún alumno haya hecho un listado de este tipo). Y hace aún más difíciles las respuestas al por qué. ¿Para qué iba a querer un miembro del personal de la universidad codificar una hoja así?

Con respecto al cómo, la opción de hacerlo manualmente siempre está ahí, pero la descarté la primera por tratarse de un trabajo de chinos, como se dice, y muy probablemente nadie se iba a tomar ese esfuerzo para nada. También existía la posibilidad de que alguien hubiese creado una fuente tipográfica con estas características, que se hubiese usado un script para cifrarlo, un programa de cifrado para dummies…

Sin embargo, era el por qué lo que más intrigado me tenía. Un amigo mío, que conoce de mi afición por la criptografía y los juegos de ingenio de este tipo, me sugirió que había encontrado a mi alma gemela en esa facultad: alguien a quien le gustaba resolver enigmas como a mí y que lo había colocado allí a ver si alguien era capaz de resolverlo (lo cual era una idea rebuscada pero que a mí me gustaba bastante). Ese mismo amigo me incitaba a que escribiese un mensaje usando el mismo cifrado diciendo que había resuelto el misterio y lo dejase colgado donde encontré el primero (lo cual era bastante difícil, pues no recordaba dónde había sido). Además, ¿qué mensaje secreto podía haber oculto en una lista de clase?

Una resolución fortuita del misterio

Mi teoría se estaba asemejando peligrosamente a los relatos de misterio de Poe. Incluso llegué a pensar que podía tratarse de algún apasionante reto del estilo del recientemente resuelto Cicada 3301. Finalmente y por motivos de falta de tiempo, deseché esa última opción, aunque me hubiese gustado continuar mis pesquisas por ahí. Así que dejé apartado el asunto durante un tiempo. Hasta que unos meses más tarde, ordenando papeles, encontré con algo que me ayudó a esclarecer el asunto. Di con lo siguiente:

Figura 5: Mi piedra rosetta para este misterio 

En la comparación de ambas páginas se puede comprobar cómo el número de letras, las líneas y la estructura del documento coinciden tanto en la versión codificada como en la que está en cristiano. Este se trataba (el de la izquierda) de un documento que mi padre me imprimió hace unos años, pero que “por error” quedó impreso así, por lo que luego tuvo que hacer una copia nueva (a la derecha). Y mira por dónde, a este documento le sucedía exactamente lo mismo que a la página misteriosa.

Ya me había topado con eso antes, pero nunca le había prestado atención. Hasta ahora. Esta evidencia viene a confirmar la teoría de que se trata de un bug en algún driver de la impresora, ya que el suceso ocurrió en dos sistemas completamente distintos.

Tras reportar el fallo de seguridad al organismo correspondiente de la universidad (el sistema de gestión informática), sin obtener hasta el momento respuesta suya, contacté con Chema Alonso para contarle acerca del misterioso caso; le pareció interesante y me ofreció la oportunidad de publicarlo en un artículo en El lado del mal, por lo que le estoy muy agradecido. ¿Y vosotros habéis tenido alguna experiencia similar? ¿Se os han desordenado las letras al imprimir algún documento?

Un saludo,

Autor: Nacho

domingo, agosto 24, 2014

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!

lunes, junio 02, 2014

Hazte un selfie para cifrar tus comunicaciones con fotones

Los algoritmos criptográficos nacen para ser rotos. Desde el momento en que un sistema es el responsable de la protección de un secreto, aparecen los ataques persiguen la ruptura de la protección del mismo para conocerlo. Es una invariante a lo largo de la historia, y al final, o bien la investigación pura y dura, o el avance tecnológico que abre la puerta a nuevos ataques antaño impensados, para acabar por servir en una bandeja plata el contenido que protege.

Hay que pensar en nuevas formas de protegerse contra los nuevos ataques, ya sea mejorando al extremo la implementación de los existentes para sacar el máximo de protección de los ya existentes o desarrollando nuevos algoritmos que puedan plantar cara al tiempo al menos mientras el secreto tenga sentido. Nada de lo cifrado hoy en día con los algoritmos usados aguantará ad infinitum.

En estos días extraños, en los que atónitos asistimos a la desaparición de TrueCrypt justo cuando estaba bajo el punto de mira en un proceso de auditoría y en plena resaca de todas las revelaciones de espionaje de NSA y sabores gubernamentales similares, la criptografía se antoja más importante si cabe como disciplina de estudio y orientación profesional.

Las explicaciones de TrueCrypt parecen vagas e inconsistentes, y las recomendaciones para pasar a Bitlocker o FileVault, cuanto menos, alejan de la historia de TrueCrypt ese espíritu hacktivista y rebelde en contra del mainstream que se había asociado a la idea de que detrás de ese proyecto se encontraba un grupo de Robin Hoods. Si bien, hay que decir que la auditoría de seguridad que se está haciendo a su código no ha dado aún con ninguna puerta trasera, aunque si como sospechan los menos confiados, solo tiene que tener una o dos, que deberían estar bien escondidas.

Los fallos en otras implementaciones de sistemas criptográficos han ido apareciendo en los sitios más insospechados, y en algunos de ellos han sido debido a los famosos números aleatorios que deberían ser de tal idem, pero que a la hora de la verdad pocas veces se consigue. Garantizar la aleatoriedad pura debe ser consistente a lo largo del tiempo, y así, la distribución de los mismos no debe degenerarse a lo largo de muchas, muchas, muchas iteraciones. Si por desgracia lo hace, entonces existirá una debilidad que reducirá la complejidad a la hora de romper el sistema de cifrado que dependa de él.

Páginas y páginas dedica el famoso libro El Criptonomicón de Neal Sthepenson a explicar estos conceptos. No deja de ser una novela, alejada de los estudios de criptografía que presenta de forma pulcra y didáctica nuestros amigos Jorge y Alfonso, pero sus metáforas sobre las mujeres sacando las bolitas de las bolsas y mirando con el rabillo del ojo, o reconociendo los números por las texturas de las esferas, no se van fáciles del ojo de la mente, que dicen los anglos. Como no, si has leído el libro, recordarás también la explicación por la que una mensaje cifrado en una baraja de cartas no debe ser protegido lanzando la baraja al aire. Cuántos momentos irrepetibles pegados al papel tiene esa novela.

Cuando estamos en pleno uso de los smartphones para hacerse selfies - hasta yo me he tomado alguno con alguno de por ahí en algún país - aparece un trabajo de esos que me encantan por ser sencillos, imaginativos y a priori muy útiles si se confirman sus enunciados. Es el caso del trabajo que lleva el nombre (QRNG) Quantum Random Number Generation on Smartphones, el cual propone utilizar, con imaginación y mucha usabilidad, la cámara esa del smartphone con la que muchos se tiran las fotos esas que arruinarán su vida futura - ha de tener al menos 8 Mega-píxeles - no solo para que el susodicho/a quede lindo/a y molón/a en las fotos sino para que se pueda leer la cantidad de fotones que hay en un haz de luz y así ponder generar un número aleatorio, que sea aleatorio "de verdad".

Figura 1: Imagen de PhysicsWorld sobre el proceso realizado (con un Nokia)

El "de verdad" lo he puesto entre comillas pues la ciencia nos depara sorpresas en el futuro, y sorprendido me hallaré dentro de un tiempo si no sale alguien capaz de crear una bombilla especial que siempre envíe el mismo número de fotones y pueda ser predicho con mayor grado de probabilidad el valor que va a capturar la cámara del smartphone. Dejo a parte por evidente, los problemas de que alguien haga como la NSA y meta un troyano en el smarphone para que cuente los fotones que ellos quieran.

El proyecto en sí lo han publicado Bruno Sanguinetti, Anthony Martin, Hugo Zbinden y Nicolas Gisin de la Universidad de Ginebra en Suiza, y plantean, como dicen en PhysicsWorld, que todos los terminales puedan contar con un chip QRNG que costaría unos 2 USD para garantizar la generación de esos números aleatorios de verdad y por ende la seguridad. de cualquier sistema criptográfico que se base en ellos. La prueba, como se ve en la imagen de la Figura 1, se hizo con un terminal Nokia o "Nokía" que dicen los anglosajones.

Figura 2: Estructura del dispositivo detector de luz para generar el QRNG

La ventaja, dicen, es que las CMOS de las cámaras de los smartphone actuales que todo el mundo lleva en su bolsillo cuando anda y encima de la mesa cuando come es que son suficientemente sensibles hoy en día como para poder capturar con exactitud el número de fotones en el haz de luz y hacer un dispositivo QRNG basándose en ellos es bastante sencillo para cualquier empresa.

Supuestamente, el sistema de generación de números aleatorios que produce es consistente en ciclos de 10 a la 118, lo que viene a ser un valor muy grande para atacar la predicción del número. Lástima que este trabajo no se haya utilizado en el juego de WatchDogs que se ha lanzado recientemente donde el protagonista, un hacker, interactúa con su smartphone. Me hubiera encantado ver al protagonista - del que me hicieron un par de montajes con Photoshop y mucho arte - tuviera que hacerse unos selfies para cifrar de forma segura algunos documentos. Hubiera sido futurista "de verdad".

Figura 3: En WathDogs el protagonista usa su smartphone para resolver las fases

Esta propuesta, tal vez podría ayudar a solucionar algunos de los citados y recurrentes problemas con la aleatoriedad en los sistemas de cifrado, que tan importantes son como se ha explicado una y otra vez para el cifrado de las comunicacones móviles, aunque insisto en que no hay que olvidar lo dicho atrás en este post y en el tiempo, que si la implementación está mal hecha, dará lo mismo la aleatoriedad de los números.

Saludos Malignos! 

sábado, abril 26, 2014

OpenSSL, GnuTLS, Goto Fail y otros bugs en criptografía

Figura 1: No Lusers 168 - Operación Bullrun en marcha

Cuando en mitad del escándalo se filtraciones de documentos de la NSA por parte de Edward Snowden salió a la luz información sobre la Operación Bullrun del GCHQ y la NSA todos nos quedamos un poco sorprendidos. ¿Cómo iba a poder la NSA inyectar errores en los estándares criptográficos?

Tras hablar unos minutos en aquel entonces con Alfonso Muñoz, uno de los escritores del libro Criptografía Digital: Del cifrado clásico a RSA, especulamos con que lo más sencillo sería meter pequeños errores en las implementaciones que no estuvieran muy auditadas. Al final, es fácil colar un error sutil en el código y que esté años generando números aleatorios que no sean tan aleatorios.

Figura 2: Diapositiva sobre la operación BullRun filtrada del GCHQ

Si has leído el libro del Criptonomicón, esto es algo de lo que se habla largo y tendido cuando se explica en detalle el trabajo de los criptoanalistas o "code breakers" en la segunda guerra mundial. "¿Cómo será de aleatorio el proceso de extracción de bolas para la generación de las tarjetas de números?".

Lo cierto es que si echamos un poco la vista atrás, el número de errores en implementaciones de soluciones criptográficas ha sido grande en los últimos años, por error humano y falta de una auditoría profunda del código.

En el año 2006, el argentino Luciano Bello localizó un error en el código de OpenSSL/Debian que hacía que se generasen claves en un rango muy pequeño, lo que hacía que pudieran calcularse todas las posibles claves en poco tiempo y se pudiese descifrar cualquier tráfico cifrado o localizar cualquier clave privada de autenticación. En este enlace tienes un seminario dictado por Luciano Bello donde lo explica en detalle y en el siguiente vídeo los 10 minutos de la explicación del error en concreto.


Figura 3: El bug de OpenSSL/Debian

En el año 2007, como recoge nuestro compañero Juan Luís en la explicación de cómo se utiliza la aleatoriedad en sistemas de seguridad se descubrió un problema en el generador de números pseudoaleatroios de Windows XP y Windows 2000 que permitía llegar a predecir los números que se iban a generar en un sistema.

En 2010 ya se tenía suficiente conocimiento y potencia como para que se rompieran las claves RSA de 512 y 768 bits, lo que dejaba descubiertos muchos certificados digitales y claves de acceso y ponía en la punta de mira de un futuro cercano las claves de 1024 bits, como explicaba Sergio de los Santos en su artículo sobre la carrera criptográfica entre Microsoft y Google.

En el año 2012 se descubrió The Flame, una ciber-arma creada únicamente para infectar equipos y robar información de ellos que llevaba viva al menos desde 2011, y que había conseguido pasar bajo el radar de todos los sistemas antimalware debido a que se había firmado el software con una certificado roto de Microsoft, lo que obligó a la compañía a cambiar todos los certificados digitales que utilizaba.

Figura 4: El certificado digital usado por TheFlame que Microsoft tuvo que revocar

En el año 2013, se analizan las librerías criptográficas de Java para la generación de aleatoriedad y salen debilidades a la hora de generar entropía necesaria para la generación de claves en determinados escenarios. Ya cuando estábamos en el proceso de creación de DUST RSS vimos que las librerías estándar de Java tenían CVEs reconocidos con problemas de aletoriedad y había que utilizar librerías externas.

En Agosto de 2013 se descubre que la función SecureRandom de Android no utiliza /dev/random - función que garantiza la entropía necesaria para garantizar la aleatoriedad, algo que por defecto, como se explica en detalle en este artículo del blog de Eleven Paths, no hace /dev/urandom.

En Diciembre de 2013 en la CCC, en la presentación de Jacob Applebaum se habla de la posibilidad que se supone que tiene la NSA para saltarse el Code-Signing de Apple en todos los dispositivos iOS e instalar apps sin pasar por la validación de AppStore. Hay que recordar que si no hay que utilizar un Provisioning Profile por cada dispositivo para instalar un troyano en iPhone. Es la Operación DropOutJeep según la NSA.

Figura 5: La Operación DropOutJeep
En Febrero de 2014, Apple saca un parche de emergencia para iOS y OS X para arreglar el bug de Goto FAIL en la verificación de certificados digitales que podría permitir, con un certificado especial, saltarse cualquier comprobación de certificado digital correcto. 
Figura 6: El segundo Goto Fail invalida todas las comprobaciones siguientes
A principios de Marzo de 2014, se confirma en una auditoría de código de GNU/TLS por parte de RedHat que hay una fallo serio en la verificación de certificados digitales que permite saltarse cualquier protección basada en claves generadas con ese software.

Figura 7: El bug de GnuTLS en las funciones de verificación de certificados

También, durante el mes de Marzo de 2014, en la conferencia CanSecWest 2014 se demuestra que el generador de códigos aleatorios de iOS 7 es inseguro, mientras que el de iOS 6 sí que era seguro.

Si a estos pequeños y no tan pequeños errores de implementación se suman los errores no conocidos públicamente, los certificados generados con algoritmos y claves inseguras, las debilidades del protocolo HTTP-s con la implementación de las reglas de confianza, las cada vez más importantes capacidades de cómputo y los exploits para todo el software implicado en cualquier sistema  que use criptografía parece que la Operación Bullrun podría haber sido un éxito.

Saludos Malignos!

jueves, abril 10, 2014

Heartbleed y el caos de seguridad en Internet

Desde que se publicó el bug de Heartbleed ha sido un día duro en Eleven Paths, como en muchas otras compañías de Internet para conseguir tener los sistemas actualizados sin sufrir interrupciones de servicio, para lo que hubo que tensar los procedimientos de emergencia y trabajar muchas horas y con intensidad. Si no te has enterado aún de qué este fallo, voy a intentar hacerte entender la magnitud del fallo para que tomes tus medidas de seguridad.

¿Dónde está el fallo de HeartBleed?

El fallo se encuentra en una de las implementaciones más populares de SSL, la capa de cifrado y autenticidad que da seguridad a muchos de los protocolos de Internet, como son HTTPs, FTPs, SSTP, o muchos otros. Según Shodan hay más de 5 Millones de servidores que tienen instalado OpenSSL expuesto a Internet aunque solo una parte de ellos tienen alguna versión vulnerable, que como sabéis ya es la 1.0.1

En concreto, el bug está en la implementación que hace esta capa de cifrado del "latido del corazón" o HeartBeat, que se usa para mantener la sesión SSL activa después del "saludo de manos" o Handshake. El funcionamiento si quieres una explicación detallada, la tienes en el libro de Cifrado de las comunicaciones digitales, pero digamos que cuando un cliente quiere establecer una sesión segura usando SSL con un servidor, lo primero que hace es negociar una clave de cifrado simétrico con el servidor que les permita enviar toda la información de forma segura. 

Para que esa clave de cifrado simétrico se intercambie de forma segura se usa un negociación, llamada HandShake, para lo que se usa el certificado digital y las claves PKI que tiene configuradas el servidor. Es decir, el servidor cuenta con us clave privada y su clave pública para firmar las comunicaciones y realizar procesos de cifrado asimétrico. Como sabéis, la gracia de PKI es que lo que se cifra con la clave pública solo puede ser descifrado con la clave privada. Por eso el servidor envía su clave pública al cliente y este usará la clave pública para cifrar la información que le va a enviar al servidor, lo que garantiza que aunque alguien intercepte la comunicación no va a poder descifrarla si no tiene la clave privada.

Una vez que el cliente ya tiene la clave pública del servidor para cifrar las comunicaciones ya pasa a negociar la clave de cifrado simétrico, usando diferentes posibles esquemas en función de las características que tengan servidor y cliente. Este proceso permitirá al cliente generar una clave simétrica y comunicarse con el servidor de forma segura lo que concluye con que tanto servidor como cliente conocen la clave simétrica de cifrado que se usará en esa sesión sin que nadie haya podido interceptarla.

A partir de ese momento se comenzarán a transmitir los datos del protocolo de aplicación que se esté protegiendo, que será HTTP, Telnet, FTP o los protocolos VPN en la red privada virtual, todo ello cifrado siempre con la clave simétrica negociada.

Como este proceso de saludo es costoso computacionalmente, se creo el "latido del corazón" o HeartBeat, que permite al cliente decirle al servidor "no cierres la sesión y fuerces otro saludo, que sigo trabajando contigo en esta sesión". Para ello en SSLv3 se envía una estructura de datos TLS1_HB_REQUEST de 4 bytes en la va el tipo el tamaño y un payload de 1 byte,  en los que se permite decir qué tamaño tiene el mensaje de HeartBeat y engañar en el tamaño a la que el servidor responde con un mensaje TLS1_HB_RESPONSE que se compone a partir del mensaje original.


Figura 1: Mensajes en SLV3 para mantenimiento del HearBeat

Y ahí está el bug.

El bug está en que el cliente puede enviar un mensaje TLS1_HB_REQUEST con un payload en el que diga que su tamaño es 65.535 (64 kB). Cuando el servidor vaya a construir la respuesta de TLS1_HB_RESPONSE va a copiar el mensaje TLS1_HB_REQUEST de memoria para a partir de él configurar la respuesta - a modo de Echo como hacen muchos protocolos -, comenzará a leer el paquete TLS1_HB_REQUEST en la posición de memoria en la que se haya ubicado hasta el final de la longitud del paquete, que la lee del mismo payload que va en él.

Como el atacante ha dicho que su tamaño de respuesta es de 65.535 leerá 64 kB de lo que haya en la memoria y lo pondrá todo en TLS1_HB_RESPONSE... todo lo que haya en 64 kB de memoria de un servidor, con lo que podrá aparecer de todo.

¿64 Kilobytes es tanto?

64 kB no es mucho si sólo vinieran los mismos 64 kB, pero es que la memoria cambia constantemente, y cada vez que se pide un TLS1_HB_RESPONSE va a venir una sección distinta. Cuando se crea un exploit para Linux o para Windows, siempre hay que conseguir un Information Leak, que permita saber en qué dirección de memoria se encuentra cargado el proceso. En este caso, basta con "pegar un tiro" con un HeartBeat malicioso y recibir una parte de la memoria. "Pegar otro tiro" y se recibirá otra parte. Brutal. Esto lleva a que la gente se pueda bajar Gigas y Gigas de datos distintos de la memoria de los servidores en pedazos de 64 Kilobytes. Brutal ++.

¿Qué se pueden llevar de la memoria de un servidor?

Todo. Claves de los servicios, el código de las aplicaciones, las cuentas de usuarios y contraseñas en texto claro de cualquier servido HTTP que corra en ellos, las claves privadas de los certificados digitales de los servidores, etcétera. Hasta el último byte de código o datos que sean utilizados en la conexión SSL en un servidor tienen que pasar por memoria, así que ahí están todas las e información que supuestamente deberían estar seguras.

Si tu servidor no tiene ningún servicio que use SSL y no tienes OpenSSL instalado y en ejecución no estás afectado, pero si uno solo de los servicios - incluso los de hosting compartido - tiene una VPN, un SSH, un HTTPs, un SSTP, o similar que tire de OpenSSL entonces todo está listo.

El bug ha afectado a muchos de los servicios claves de Internet. Google conocía este bug desde diciembre de 2013 y aún está actualizando servidores para evitar el impacto. Yahoo! está enfangado en las actualizaciones, Amazon ha avisado a todos sus clientes de sus problemas pidiendo las passwords, y... hasta nosotros nos vimos afectados en los servidores, lo que nos obligó a lanzar un procedimiento de emergencia notificando .

¿Qué se debe hacer?

En el caso de que tu servidor haya sido afectado debes hacer un cambio de cualquier clave que tenga el servidor. Todas deben ser cambiadas. De servicios, de conexiones a bases de datos, árboles LDAP, de cifrado de disco, de administración de servicios, de todo.

Si tienes un servicio por encima, tipo FTP, HTTP, etcétera, debes asumir que todos los datos que se hayan transmitido han podido caer en manos indebidas, así que cambia las credenciales de todos los usuarios de aplicaciones web, fuerza un reseteo de contraseñas, mata las cookies de sesión de todas las conexiones que hubiera activas y asume que todo tu código ha caído en manos externas.

Por supuesto, hay que cambiar los certificados digitales de todo que pueden estar comprometidos - las claves privadas de los certificados están también en memoria - y por tanto si alguien las ha obtenido puede utilizarlas para descifrar todas las comunicaciones a tu servidor y ver el tráfico.

Cambiar los certificados digitales no es nada sencillo, ya que si tienes apps que hagan uso de Certificate Pinning deberás actualizar los certificados que validan dichas apps, así que espera que tu Android, tu iPhone o tu Windows Phone empiecen a pedir actualizar apps a saco. 

Desde el punto de vista de usuario, no solo deberás actualizar las app, sino que como no sabes qué credenciales han podido caer en qué servidor, deberías cambiar todos las passwords. Si no tienes un 2FA, es un buen momento para ponerlo en tu cuenta de Google, Hotmail o Apple y asegurarte que toda las cuentas cuentas de servicio tienen como correo electrónico de recuperación de contraseña una cuenta con Segundo factor de autenticación.

En muchos frameworks de Internet basados en sistemas Linux, como WordPress, PrestaShop, Moodle, Joomla, RoundCube, etcétera, etcétera, es muy común el uso de OpenSSL, así que por si acaso algunos de tus usuarios no ha cambiado la contraseña, dale un vistazo a la posibilidad poner un segundo factor con Latch.

Si tienes muchos servicios en tu Hosting, afina los firewalls y los IDS para detectar esos paquetes de respuesta de TLS1_HB_Reponse de 64 kB.

¿Esto una puerta trasera o un fallo de programación?

Como os podéis imaginar las especulaciones apuntan a que esto es la famosa "capacidad avanzada" que el programa BULLRUN filtrado por Edward Snowden hablaba. No tiene sentido que OpenSSL tuviera un fallo gordisimo años atrás que permitía descifrar el tráfico, que Apple no sea capaz de verificar los certificados digitales de forma correcta en el escándalo del Goto Fail y que se hayan descubierto fallos similares en otras implementaciones de cifrado.

Figura 2: Filtración del programa BULLRUN

Las especulaciones decían, según los documentos filtrados, que la NSA podría haber impulsado la inyección de errores en las implementaciones más usadas de software criptográfico y por supuesto todo el mundo miró a TrueCrypt - actualmente bajo estudio pero con pocas noticias - y OpenSSL

Sea como fuere, este bug está entre el Top 10 de bugs de seguridad en Internet seguro por la facilidad de explotación y su impacto. Solo el RCP DCOM o el MS08-67 - que hace las delicias de los que comienzan a aprender a usar Metasploit - de Microsoft creo que se podrían igualar. En esos podías ejecutar remotamente una shell con un exploit bastante sencillo, en este puedes conseguir los datos de forma silenciosa - los HeartBeats no dejan traza en los servidores web - esperar a que llegue la password y entrar.

Actualización: Detección con Faast

En Faast, nuestro servicio de Pentesting Persistente en Eleven Paths hemos introducido ya el plugin de detección de Heartbleed para localizar servidores vulnerables en nuestros procesos de auditoría.

Figura 3: Detección de Heartbleed con Faast

Saludos Malignos!

martes, enero 07, 2014

No Seas Así

Desde que escribí el artículo de 0wn3d! (o cómo la NSA acabó con el espíritu de Internet) han seguido sucediendo más y más noticias que tienen como protagonista a la misma Agencia de Seguridad Nacional. Algunas de ellas las he ido recopilando por aquí, como el espionaje en el Vaticano y el intento de capturar el tráfico de Google y Yahoo!,  los documentos filtrados sobre historias en las que los agentes de espionaje utilizaron el poder en su uso personal, el sistema Sinapsis para analizar todos los metadatos o el reconocimiento público del poder sin parangón en temas de ciberespionaje.

Figura 1: "- La NSA no violaría nuestra privacidad, ¿verdad?"
"-Bueno, no a proposito" 
- Así es, sería totalmente por accidente... ups!"

Muchas otras noticias no las he podido tratar por aquí porque si no éste blog se hubiera convertido en un auténtico monográfico sobre las acciones de esta agencia, pero a final del año volvieron a saltar los escándalos referidos a asuntos impactantes.

El primero de ellos es el que tiene como protagonista a Apple y su posible colaboración en el programa DropOutJeep de la NSA que fue explicado por Jacob Applebaum en la ya pasada 30th del CCC en Alemania. En su presentación se hablaba de este sistema para troyanizar el 100% de los terminales iPhone con software de espionaje controlado por la NSA, algo que según el ponente no podría hacerse sin la colaboración de Apple.

Figura 2: Programa de espionaje de iPhones DropOutJeep

Apple respondió que ni lo ha hecho, ni lo hará, ni lo haría en una contestación en la que se le notaba bastante molesto ya con el tema. No hay que olvidar que a las empresas tecnológicas norte-americanas todos estos escándalos les ha costado un autentico dineral en pérdida de negocio por culpa de pérdida de confianza y regulación estatal contraria a sus intereses de expansión.

El segundo de los escándalos tuvo que ver con la supuesta colaboración de la RSA con la NSA para poder meter un backdoor en los algoritmos de cifrados utilizados a cambio de una suma de dinero. La noticia hizo mucho daño a la empresa y una de las conferencias más importantes del sector, la famosa RSA de San Francisco se vio seriamente perjudicada bajo las críticas de profesionales reconocidos del sector.

Mikko Hypponen (@mikko), cabeza visible de F-Secure y reconocido experto en seguridad informática, renunció a participar en las conferencias por este escándalo. Tuve la suerte de tomarme algo con Mikko en una fiesta de la BlackHat USA 2012 y no me sorprendió una respuesta así, que de hecho ha llevado más allá, dando conferencias sobre el derecho a la privacidad, como en la última TEDxBruselas.

Figura 3: Mikko Hypponen "Privacy is not negotiable"

La forma en que la NSA podría haber puesto un backdoor en el código de cifrado de RSA se explica de una manera magistral por Nick Sullivan, ex-ingeniero de Apple especializado en criptografía y miembro actual de CloudFlare dentro de un artículo titulado "How the NSA (may have) put a backdoor in RSA's Cryptography: A technical primer".

En su artículo - que se entiende mucho mejor si has leído el libro de Criptografía: de la cifra clásica a RSA - explica cómo se puede introducir un factor de error el uso de cifrados de curva elíptica haciendo que los dos números base estén relacionados entre sí, haciendo que sea prácticamente indetectable, y al mismo tiempo factible, descifrar cualquier código cifrado.

Figura 4: Esquema básico de generación de números pseudoaleatorios

La demostración feaciente de que una falta de aleatoriedad puede ayudar al descifrado de las claves tiene su exponente en el ejemplo del bug en OpenSSL descubierto por Luciano Bello que le hizo merecedor de un Pwnie Award.

Para poder descifrar todos estos códigos la noticia final de esta historia es que la NSA está trabajando en un computador cuántico, algo que lleva décadas siendo algo teórico pero que muchos apuntan a su posible existencia en corto espacio de tiempo. La posibilidad de que se pudiera crear un computador cuántico de estas capacidades supuestamente permitiría a la NSA romper cualquier sistema de cifrado actual, debido a la potencia de cálculo, aunque sin embargo, como explican en detalle en el Whashington Post, esto aún no es realidad.

Estas tres noticias, más todos lo demás trucos que se han ido publicando con backdoors en firmware, faxes con troyanos, cables infectados, BIOS controladas con software de espionaje, troyanizar satélites según los Emiratos Árabes, etcétera, etcétera, hacen que las películas de ciencia-ficción necesiten pensar en cosas que a día de hoy no hayan sido implementadas, ya que muchas de las cosas que hemos visto en los últimos meses han sido, cuanto menos, sorprendentes.

Figura 5: Edward Snowden recibiendo un premio en Moscú

Por último, no me gustaría terminar este artículo sin hablar de la transformación que han sufrido durante los últimos meses las imágenes públicas de la NSA - que tuvo el valor de ponerse delante de los expertos de seguridad para decir que hacían lo correcto - y de Edward Snowden - que partía como el enemigo del pueblo de los EEUU número 1 -. A día de hoy, hasta el presidente Barack Obama ha sido claro al decir que la NSA debe cambiar y no espiar todo solo porque pueda hacerlo, y Edward Snowden comienza a tener una vida pública recibiendo premios y reconocimientos a su valor por una gran parte del público de Internet.

Saludos Malignos!

lunes, noviembre 25, 2013

Credenciales de Facebook enviadas por HTTP y no HTTPs

Tras las demos del programa de televisión, lo que mucha gente preguntó fue eso de "¿No van las credenciales de Facebook siempre por HTTPs?". Eso les llevó incluso a pensar que la demostración que hice pudiera no funcionar o que fuera de cartón piedra. Con el objetivo de que entiendan mejor en que consiste el ataque, he hecho este artículo y un par de gráficos para que lo entiendan mejor, pero si quieres más, puedes leerte el libro de Ataques en redes de datos IPv4 & IPv6.

El primer punto que hay que conseguir es situarse entre medias de la comunicación. Esto se puede hacer de mil formas, desde configurarse como rogue-AP y router a nivel de red, hasta hacer un ataque de ARP-Spoofing, pasando por los ataques Stateless Adrees Auto Configuration en IPv6 o Web Proxy Auto Configuration en IPv4 o IPv6.  Estos tres últimos los puedes hacer con Evil FOCA.

Figura 1: Esquemas de la interconexión IPv6-IPv4 para hacer el man in the middle

Una vez que se está en medio, se tiene acceso al tráfico que se está enviando desde el cliente, y si se tiene acceso a él, existe la posibilidad de poder interceptarlo y manipularlo, que es lo que hacen herramientas como Cain, SSLStrip, SSLSniff, Ettercap en Kali o la Evil FOCA.

Un Fake CA

Según la herramienta para atacar la red que utilices, el comportamiento será uno u otro cuando hay que lidiar con conexiones HTTPs. En el caso de Cain, la herramienta hace una copia del certificado digital original para enviarle al cliente un Fake-CA. Algunas herramientas no validan que el certificado digital cumplan que el certificado esté emitido para ese sitio, que esté caducado o que esté emitido por una entidad certificadora válida en la que se confía, como por ejemplo publicamos con el cliente aMSN. Con el resto de ellas, o bien no funciona la conexión, o se obtiene una alerta de seguridad.

Figura 2: Certificado falso de passport.com creado por Cain

Si el usuario acepta ese certificado, a partir de ese momento estará enviando los datos cifrados al atacante, que los descifrará, leerá, manipulará y los volverá a enviar al servidor cifrados con una conexión HTTP-s hecha, esta vez sí, con el certificado original del servidor web.

El bug de las BasicConstraints

En el caso de SSLSniff, lo que se hace es algo similar, pero aprovechándose de un bug en los clientes que no verifican las BasicConstrains del certificado que reciben. La gracia es que se utiliza un certificado auténtico pero que no tiene validez para crear nuevos certificados. Es decir, supongamos que el atacante se saca un certificado digital para un servidor web llamado miserver.com en Verisign. La cadena de confianza es correcta, y no genera ninguna alerta de seguridad.

El ataque se basa en usar el certificado de miserver.com para crear certificados digitales falsos para sitios como www.facebook.com pero firmado por miserver.com. Si el cliente tiene el bug de BasicConstrains y no comprueba que el certificado de miserver.com no tiene autoridad para crear certificados, podría tomar el falso certificado de facebook.como como bueno. Esto le ha pasado a casi todos los navegadores, y al propio iOS de iPhone no hace mucho.

El Stripping de HTTPs

En el caso de herramientas como SSLSniff o Evil FOCA el ataque se basa en hacer que el cliente navegue entre él y el atacante con HTTP y luego las herramientas navegarán con HTTPs cuando se conecten al servidor oficial. Aquí tenéis la presentación original de Moxie Marlinspike en BlackHat 2009.

 
Figura 3: 2009 BlackHat DC Presentation on SSL Stripping de Moxie Marlinspike

En el caso de que el servidor haga un re-direct a HTTPs, como sería por ejemplo cuando el cliente pida http://www.google.com y el servidor le intente llevar a https://www.google.com, será el atacante el que hará la redirección, manteniendo al cliente siempre en HTTP.

Figura 4: El Bridging HTTPs-HTTP con un redirect de por medio

Una vez que se obtenga la página de resultados, es importante que las cookies de sesión - que vendrán marcadas con el flag secure para no funcionen sobre HTTP - sean gestionadas por el atacante. Para ello se puede generar una cookie falsa que se envía al cliente sin dicho flag, permitiendo que él navegue, y que el servidor no note que ha habido una manipulación de la cookie.

Figura 5: La captura de las credenciales vía HTTP en el equipo que corre la Evil FOCA

Esto no es necesario siempre. Muchos servidores que hacen el envío de un mensaje de redirect a HTTPS, siguen escuchando por HTTP, así que aunque pidan que todo se le envíe por HTTPS se puede seguir enviando la información de login por HTTP y permiten la autenticación.

Para conseguir más peticiones de inicio desde el cliente con HTTP, Evil FOCA filtra los resultados de Google, es decir, que si te conectas a Google a través de una conexión atacada por Evil FOCA poniendo en la barra de navegación http://www.google.com, cuando el servidor devuelva un redirect a https://www.google.com, Evil FOCA lo interceptará, hará la navegación a HTTPs y le entregará la página de búsqueda al cliente bajo HTTP. Es decir, hace un Bridging HTTPs-HTTP a www.google.com

Figura 6: Evil FOCA haciendo el Bridging a WWW.GOOGLE.COM y a los resultados de búsqueda de Facebook

Después, cuando el usuario busque en Google algo como Facebook, todos los resultados que vengan apuntando a HTTPs serán sustituidos por HTTP y los redirect Javascript serán eliminados también, para que el engaño sea completo. El resto, será volver a hacer el Bridging HTTP-HTTPs otra vez, pero esta vez a Facebook. Esta es la demo que hice en DEFCON 21.

Mitigaciones

Si estás en un esquema de man in the middle hay poco que hacer salvo cifrar contra un punto de conexión seguro con una VPN con L2TP o SSTP con Certificate Pinning - que PPTP es susceptible de ataques de man in the middle y se puede crackear por diccionario o atacando MS-Chap-v2 con brute-force tras reducción - , y si no es posible mejor que no se navegue nunca. Un plug-in que obligue a navegar siempre vía HTTPS, el uso de certificate pinning para evitar que te comas un bug de BasicConstrains en el futuro o un entidad intermedia maliciosa, además de intentar no entrar a los sitios haciendo clics en ningún sito o confiando en los redirects a HTTPS ayudarán mucho a detectar el ataque.

Saludos Malignos!

miércoles, octubre 30, 2013

Ganó 1.000.000 $ con una inversión de 27 $ en Bitcoins

Esta mañana cuando he leído la noticia me ha dejado sorprendido, y no creo que por hacer un paper de investigación sobre criptografía se suela ganar tanto, pero a veces la fortuna te alegra la vida de la forma menos esperada, como a este estudiante de Noruega.

Figura 1: El estudiante noruego protagonista de esta historia

El curso de los acontecimientos es sencillo. Un estudiante de criptografía decide comprar hace 4 años unos Bitcoins - la moneda criptográfica de la que tanto se habla - para estudiar mejor el sistema de intercambio que utiliza - algo de lo que se mofó su novia -. Como buen estudiante su inversión no es ni mucho descabellada, así que invierte 27 dólares americanos que le alcanzaron para comprar nada más y nada menos que 5.000 Bitcoins en aquellos tiempos.

Figura 2: El paper académico que da soporte a los bitcoins

Hoy en día es fácil de entender que 5.000 Bitcoins pueden tener un valor mucho mayor, algo que él también comprendió, lo que le llevó a buscar la clave de acceso a su wallet para sorprenderse con una fortuna de más de 886.000 USD en bits criptográficos. Hoy ya su precio en el mercado, esos 5.000 Bitcoins, valen más de 1.000.000 USD, pero él ha decidido invertir parte de su fortuna digital en comprarse un apartamento en una de las mejores zonas de Oslo - y darle en los morros a su novia, suponemos -.

Figura 3: Últimas operaciones de cambio de Bitcoins

En las gráficas se puede ver como ya en muchos mercados se ha pagado el cambio de un Bitcoin a más de 200 USD, lo que es una autentica brutalidad comparada con su valor hace apenas 4 años. Sin embargo, para muchos inversores el gran problema con los Bitcoins sigue siendo su inestabilidad de cambio.

Esta moneda sigue viéndose muy ligada a la Deep Web - a pesar de que cada día más comercios de Internet y de la vida física la admiten como medio de pago legal - y cualquier incidente en ella, como el cierre de SilkRoad o la interceptación de Bitcoins por parte de los cuerpos de seguridad americanos, hace que su caída sea brutal en corto espacio de tiempo. Ni que decir tiene, que cuando lo que hay por medio es un robo de Bitcoins, la cosa aún es peor, porque genera mucho más pánico entre los inversores habituales en otros tipos de divisas.

Figura 4: Variaciones del valor de los Bitcoins en los últimos meses

Este miedo a la fluctuación que da pánico a tanta gente, contrasta por otro lado con la alta rentabilidad que se puede conseguir en poco tiempo, ya que casos como el de este estudiante son muy comunes con muchas personas que yo conozco, que con pequeñas inversiones en Bitcoins han conseguido un poco de dinero fácil solo dejándolos olvidados por un tiempo. ¿Tú tienes Bitcoins?

Saludos Malignos!

Entradas populares