lunes, 19 de agosto de 2013

Nostalgia: Manual del Amstrad CPC 6128

A pesar de que soy joven y no coincidí temporalmente con los amstrad CPC, por casualidades de la vida he acabado teniendo por casa un CPC 6128 a mis 11 - 12 años, y si bien había cosas que me molestaban mucho como por ejemplo que la disquetera del mío estaba estropeada (me lo habían regalado de segunda mano), guardo un grandísimo recuerdo de él y de su pantalla de fósforo verde. Lástima que mis padres lo hayan tirado un día que yo no estaba "porque ya no servía para nada". Sin embargo, cuando me lo dieron recuerdo que me dijeron "Oye, ¿el manual lo quieres?". Y yo estuve a punto de cagarla y decir que no, sin embargo dije "Pues vale", y me lo empecé a leer.

Me encantó, aprendí muchísimo y bajo mi punto de vista el manual estaba escrito de perlas, para la época quizás mucho mejor que algunos libros técnicos actualmente.

De hecho, tengo que reconocer que por curioso que sea aprendí a programar más o menos en el año 2000 con libros de ordenadores antiguos. Antes el manual del PC no era sólo 3 chorradas, si no que te enseñaban a programar en el lenguaje BASIC, que era el intérprete por defecto del sistema.

Además, cada ordenador de la época tenía distintas instrucciones. El más placentero para programar de los que he probado físicamente ha sido el MSX, ya que además era el que más instrucciones y funciones tenía. Recuerdo por ejemplo la declaración de Sprites y la detección de colisiones para programar videojuegos.

Salvo el libro del CPC que era mío (y aún conservo, cuando vuelva a España tengo que encontrarlo), el resto de los libros los fui cogiendo en préstamo de la biblioteca municipal.

Me dió mucha pena que hace poco después de varios años sin ir volví y habían reformado la biblioteca entera, y de esos libros no quedaba nada. En el estante sólo había cosas como Excel 2010, Access 2007, Dreamweaver, algo de Visual Basic 6 y alguna otra cosilla. Ninguno de los libros que me habían enseñado tanto y que serían tan válidos hoy en día como lo fueron para mí hace 10 años sobrevivieron.

Por eso hoy me sentí tremendamente nostálgico y alegre cuando encontré un sitio web de fanáticos del Amstrad CPC, y entre ellos estaba el manual de mi querido Amstrad CPC 6128. Recomiendo al menos echar un ojo al último capítulo de la historia de la informática y de cómo el tío predice que cuando baje el precio de la memoria se podrán ver películas en un PC...

Por último, si me lee alguno de los hachas que se ha matado a escanear el manual entero, muchas gracias!

lunes, 12 de agosto de 2013

Ataque BREACH, un toque de atención a SSL/TLS/Cualquier tipo de cifrado realmente

Estando desconectado temporalmente del tema de la seguridad, un Security Advisory de Django me volvió a traer al mundo de los vivos. El tema viene siendo éste:

https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/

Donde avisan del ataque BREACH. Por supuesto, me puse a indagar sobre el tema y echar un ojo al PAPER que presentan, ya que me sorprendió ver que TLS/SSL (y realmente cualquier tipo de cifrado!) eran vulnerables al ataque.

El ataque se basa en uno anterior, CRIME, basado en la comprensión TLS, que no es demasiado común. Ésto va más allá usando la comprensión básica que va sobre HTTP, es decir, antes de realizar ningún tipo de cifrado del tráfico. Es muy común en cualquier tipo de web, tanto usando HTTP como HTTPS, usar algún tipo de compresión para ahorrar ancho de banda, eligiendo muchas veces la compresión gzip.

El ataque tiene varios requisitos:
  • Un servidor que use compresión a nivel HTTP (cae de cajón)
  • Que aparezca algún parámetro introducido por el usuario en el body de la respuesta HTTP
  • Que haya algo "interesante" en el body de la respuesta (un token CSRF, por ejemplo). Algo secreto que queremos robar.
Y ahora empieza la gracia. Si tenemos una petición tal que:

GET /owa/?ae=Item&t=IPM.Note&a=New&id=canary=<guess> 

Y nos devuelve algo como (esto lo hace Outlook Web Access):

<span id=requestUrl>https://malbot.net:443/owa/forms/
basic/BasicEditMessage.aspx?ae=Item&amp;t=IPM.Note&
amp;a=New&amp;id=canary=<guess></span>
...
<td nowrap id="tdErrLgf"><a href="logoff.owa?
canary=d634cda866f14c73ac135ae858c0d894">Log
Off</a></td>


Guess sería lo que nosotros inyectamos. Gzip intenta buscar coincidencias de palabras para comprimir la respuesta. Por lo tanto comprimirá canary= al tenerlo en dos partes (en el ejemplo) de la respuesta. Pero qué pasa si intentamos inyectar cosas? El tamaño de la compresión será el mismo si no acertamos pero si acertamos y metemos canary=d... al encontrar canary=d634... en otra parte del texto la compresión será mejor, y la respuesta por parte del servidor más pequeña. Esto permite que repitiendo el ataque podamos ir sacando, byte a byte, el token.

Y ya el tema de cómo explotarlo, pues a partir de ahí a echarle imaginación. Lo difícil es llegar hasta estas conclusiones. Me he saltado varios detalles que son relevantes, para más información echad un ojo al PDF.

Por último comentar que me gustó ver que uno de los investigadores involucrados es el lugués Ángel Prado, habitual speaker en las Jornadas de Seguridad de A Coruña, y al que espero poder ver este año a finales de octubre en GSICKMINDS (nuevo nombre de dichas jornadas).

Un saludo a todos!

jueves, 1 de agosto de 2013

BlockPrism, cifrando el chat de Facebook

Buenos días a todos, se que llevaba mucho tiempo sin escribir, pero mi vida se me ha puesto de arriba a abajo en apenas un mes (para bien), ya contaré algo de eso.

En este caso os quiero presentar una herramienta que me ha parecido muy útil, sobre todo con todo el jolgorio que se está montando con el tema Snowden.

La idea consiste en algo tan sencillo como una extensión de explorador (por ahora disponible para chrome) que activada en el sitio web de facebook activará un cifrado basado en criptografía asimétrica.

Como entidad de confianza dependemos del servidor del creador de la aplicación, que afirma guardar únicamente el id del usuario de facebook y su clave pública, es decir, lo mínimo indispensable para mantener un sistema de cifrado asimétrico en el que no se tenga que hacer un prenegociado de claves (estilo SSL), ya que de esa manera se perdería la funcionalidad de los mensajes online. Para más confianza al parecer el proyecto va a ser OpenSource, con lo cual cualquiera podrá revisar el código y ver lo que realmente está haciendo el usuario.

Sin más dilación os dejo el enlace del proyecto: http://blockprism.org/ y la dirección de su campaña en IndieGogo .