how to hack a h4ckc0nt3st

Hace unas horas acabo de volver de A Coruña, donde pasé unos excelentes días entre charlas y talleres de excelente nivel técnico y amigos en las Jornadas de Seguridad Informáticas organizadas por GSIC.

Pero este post tiene otro objetivo que contar lo lindo que fue. Así que si esperabas algo blando, puedes dejar de leer acá :P (las fotos estarán online en breve). Lo que sigue es la respuesta larga a la pregunta que me realizaron varias veces en los últimos días: ¿Estas jugando al h4ckc0nt3st?. La respuesta corta era sí, lo estoy haciendo en este exacto momento, aunque no de la forma tradicional.

El contexto

Durante la conferencia, Miguel organizó un muy divertido hack contest. El objetivo era llegar a una respuesta a través de la resolución de diferentes desafíos. Dicha respuesta se metía en un formulario web (que escuchaba en http://10.20.63.1:666) y de esta forma se acumulaban puntos.

El hack

Dado que la red sobre la que se hacía el concurso era una wifi abierta y que el servidor recibía las respuestas de los participantes en texto plano (no usaba SSL), pensé que sería divertido escuchar las respuestas de los demás concursantes. El paso siguiente de enviar dichas respuestas a mi nombre resultó inevitable. De esta forma, cada vez que alguien enviaba una posible respuesta a un desafío, yo también respondía lo mismo. Logré automatizar ello con las siguientes líneas:

tshark -T fields -e data -i mon0 -R 'ip.dst == 10.20.63.1 and tcp.dstport == 666 and ip.src != mi.propia.ip ' | ./loro.py

Donde loro.py este archivo:

loro.py   

La explicación

Tshark es la versión de consola de wireshark. Este toma los paquetes de una interfaz en modo monitor (lee esto para aprender cómo). El modificador -f es el encargado de darme solo aquellos paquetes que vayan al servidor. Excluir del filtro a mi propia IP evita que el sniffer vea mis replayes y entre en loop (tardé en darme cuenta de esto, perdona Miguel por floodear tus logs). El script loro.py recibe el campo data de los por stdin (línea (#) 5), lo decodifica en ascii (#7), y chequea si es una respuesta (#8). Después lo divide y busca la cookie (# 9 a 11). Al encontrarla, la reemplaza por mi propia cookie (#12, fue una suerte práctica que no caducara). Luego vuelve a juntar todo (#13), lo imprime en stderr (#14, con fines de logging, nada más) y lo envía de nuevo al server (# 15 a 18).

Como dicen por acá, ¡a que mola!

¡Nos vemos en España!

Gracias los grandes esfuerzos de Diego el gallego y Chema josemaricariño visitaré España en algo menos de un mes. Las excusas son las jornadas de seguridad organizadas por GSIC y los labs de la RootedCon. Así que vamos por partes.

Qué: Daré un taller sobre seguridad en sistemas Linux
Dónde: En el Campus de Elviña de la Facultad de Informática de A Coruña.
Cuándo: Las jornadas son entre el 24 y el 26 de Febrero.
Qué hay que hacer para asistir: La asistencia es gratuita con previa inscripción, la cual aún no está abierta pero lo estará pronto (posiblemente sea anunciado en @ficsecurity). Hay unas 25 plazas disponibles.
El taller será netamente práctico y será de unas 5 horas, por lo que tengo entendido. Trataremos temas de seguridad básica, como el acceso discrecional, la administración de recursos y PAM. Está orientado a iniciados en la administración de sistemas Linux-like.



Qué: Haré una introducción a la criptografía en uno de los Labs, previos a RootedCon
Dónde: En las Instalaciones Madrid On Rails, en Madrid.
Cuándo: Los Labs son entre 28 de Febrero y el 2 de Marzo. El mío en particular será durante el 1º.
Qué hay que hacer para asistir: La asistencia requiere inscripción previa y tienen un coste de 200 € + IVA. Hay 12 plazas disponibles.
Se puede acceder al temario aquí, aunque puede que dé una incorrecta impresión. En el momento que lo escribí hice demasiado foco en la parte matemática (aburrido!!). Si bien aún lo estoy preparando, el cursillo tendrá un foco mucho más programático. El objetivo es la mejora de decisiones tecnológicas cuando impliquen criptografía. Haremos prácticas en OpenSSL, SSH y PGP.

¿Nos vemos allí?

secure information flow analysis: my first steps

During the last months and have been reading a lot about information flow analysis, with the remarkable Eduardo Bonelli's guidance.

Some months ago, as an exercise, I wrote two analyzers for a really short command set of Python (while, if and assign). Before remove that directory, it occurred to me that may exists a remote possibility that someone might find it interesting. So here it is, with a quick and dirty introduction to secure information flow.

The goal, in short words, is to avoid that variables tagged as secret (high confidential level) doesn't leak to public variables (low confidential level). This may happen in two ways:

  • Explicit: A high variable is assigned to a low variable
  • public:=secret

  • Implicit: A low variable content depends on the content of a high variable
  • if secret == true
    then public:=true
    else public:=false

If there is no leak, we said that the code satisfies non-interference (wikipedia link). You can learn more about secure information flow analysis in the web. In my humble opinion, this is a good introduction.

A typical way (certainly not the only one) to detect these leaks is with type systems. This was the approach in both analyzers. The first one is a sort of an implementation of a fundation paper, by Volpano et.al.. I made an algorithm version (probably wrong) of the typing rules exposed in the paper. The code is here. This type of analyzers are called Denning-style, because Denning and Denning introduced those concepts in a 1977 paper.

The second analyzer (the code is here) is based on the formalism presented by Hunt and Sands in this paper. It's a dynamic analyzer (Denning-style analyzers are static), which means that the non-interference can be broken in subprograms and still be good as a whole. This may be a little tricky. For example, this code is secure (the leak was overwritten with a 0) even when a subprogram (without the last line) is insecure:
public:=secret
public:=0

Anyway, that's all for now. The analyzers are written in Python, using the Abstract Syntax Trees module and python-lattice (yes, this is what that stupid library is for). If you want to play more, here is a tarball with the code, the papers and few examples to analyze.

eventé, eventando y eventaré

He estado (y lo estaré) de evento en evento. Así que acá va un pequeño resumen. Tal vez a alguien le sea útil o pueda lamentarse de no haber ido a aquellos que ya ocurrieron. Si tenés pensado ir a alguno en donde nos encontremos, no dudes en inscribirme para tomar una cerveza.

En el pasado:

En el futuro:

  • 10º Jornadas Regionales de Software Libre: En San Luis, el 28, 29 y 30 de Octubre. Este año no podré asistir, pero se corre la bola de que va a estar muy muy buena.
  • Google DevFest 2010 Argentina: En Buenos Aires, 1 y 2 de Noviembre. Si bien la inscripción ya debería haber terminado, yo lo hice fuera de termino y parece que tengo la confirmación. El procedimiento requiere dar respuesta un breve quiz.
  • BSDday Argentina 2010 (una web muy geek): En Buenos Aires, 5 y 6 de Noviembre. Me inscribí hace meses y no voy a poder ir (por la razón que se comenta en el siguiente item). El año paso la pasé muy bien y este año las charlas realmente prometen.
  • 6º Jornadas de Software Libre: En Junín, 5 y 6 de Noviembre. Hablaré Linux Capabilities y Hardening. Muchísimas gracias a los organizadores por invitarme. El programa se ve muy interesante y será una excelente oportunidad para reencontrarme con amigos y visitar la ciudad.

removing your facebook photo tags automagically

Este post también está escrito en español aquí.

Privacy at Facebook is heavy-duty. As a big fan of the Worlds Collide Theory I hate be tagged compulsively. I would like to select in which photos appear in my profile and feed. Since I couldn't find that option in the setting menu, I looked for the answer in my favorite scripting language: Python.

This 60-lines-long script removes your tag from the latests photos where you has been labelled. You can download it from here. You may run it hourly (or every 15 minutes, or every 5 minutes, depends how paranoid you are) via cron or whatever.

Any improvement is welcome. It probably runs on Windows too. If you managed to do it, leave a comment for the others.

NEW VERSION! (available here).

remover tu etiqueta de las fotos de facebook automágicamente

This post has been written in English too.

La privacidad en Facebook es un asunto complejo. Como gran suscriptor a la Teoría de Colisión de Mundos es que odio ser etiquetado en fotos de forma compulsiva. Me gustaría tener alguna forma de elegir en que fotos aparezco en mi perfil y actualizaciones. Dado que no pude encontrar tal opción entre la configuración, busqué la respuesta en mi lenguaje de scripting favorito: Python.

Este script de 60 lineas remueve tu etiqueta de las últimas fotos donde te hayan tagueado. Puede ser descargado desde aquí. Hay que correrlo cada hora (o cada 15 minutos, o cada 5, dependiendo de que tan paranoico seas) a través de cron o como sea.

Cualquier mejora es bienvenida. Posiblemente también corra en Windows. Si lograste hacer esto, deja un comentario que pueda serle útil a otros.

¡NUEVA VERSIÓN! (disponible aquí).

lappy back & manizales

La noche de 26 de agosto, mi laptop dejó de encender. Para ser estrictos, encendía pero se reiniciaba al segundo, antes de que el video levante. Desde la mañana del 27 ha estado pasando por varias manos de distintos servicios técnicos. Desde ese momento me vi forzado a tratar con soluciones temporales (como la comentada en este post) y lectura de correos en webmails. Finalmente, el viernes pasado decidí, para resolver el problema de cuajo, comprar un motherboard nuevo y ya. Resultó ser mucho más expeditivo y solo costó una fracción del arreglo. Así, el lunes, a solo 4 horas para partir a Colombia, me reencontré con mi amada lappy en perfecto estado de funcionamiento. ¿Y el motherboard viejo?

Después de más de un mes sin bajar correos, la cosa se puso algo espesa.


Ahora tengo cantidad de cosas en mi ToDo List. Y para echar más leña, esta semana tampoco será de lo más productiva. Ponerme al día me llevará un tiempo.

En cuanto al paso por Colombia, aún sigo aquí. La estoy pasando de maravillas, me he encontrado con varios viejos conocidos (incluyendo Chema y Gunnar) y la organización me hace sentir como en casa.

En este 3º Encuentro Internacional de Seguridad Informática me convoca dos temas bizarros, el primer por viejo y el segundo por clásico. Es que volver a hablar de OpenSSL hace que tenga que sacudir el polvo de viejos slides. Pero hablar de Kryptos, es aún más raro y genial. Los slides estarán disponibles en este post, seguramente en estos días. Junto con las fotos.

UPDATE Wed, 14 Oct 2009 12:23:29 -0300: Las diapos, de la charla de OpenSSL y de la de Kryptos. Enjoy them! (las fotos, con un poco más de tiempo)

conectando facebook con wordpress

Dado que mi status de Facebook degeneró en microblogging, instalé (y modifiqué levemente) este plugin de Brian Goad.

Mi versión modificada puede bajarse de aquí y permite folding y publicar el RSS del status para sindicar. Esta última opción hace pública tu key. Siendo que es obvio que tu status es público y que no podes usarlo para cosas sensibles.. ¿a alguien se le ocurre las consecuencias que esto conlleva?

On tour (bonus stage): 25C3 - Berlín, Alemania

Primero lo primero: Madre, estoy vivo. Y ya no estoy en Berlín, sino en Amsterdam.

Cumplido ello, al foco. Tuve la oportunidad de participar del 25th Chaos Communication Congress (25C3), lo que fue una experiencia realmente increíble. La gente, los anuncios, las mesas de distintos proyectos y todas esas cosas hicieron de CCC uno de mis eventos favoritos.

El año terminó y con él el tema del bug de OpenSSL/Debian. Solo me queda entregar mi informe en el posgrado y defenderlo, pero espero terminarlo cuanto antes y enterrar así el tema. Es hora de cosas nuevas.

En cuanto al resto, pasé un fin de año muy atípico. Con amigos y desconocidos. Raro pero bien. También en estos días me encuentro aplicando para un interesante puesto laboral (como dudo que se concrete, no daré más detalles), con lo que es algo más en mi cabeza. Durante una caída, mi cámara de fotos dejó de funcionar como corresponde, así que pueden ver las fotos de terceros en estos lugares: las de Machu y las de Maxi. Estoy tratando de hacer una subselección para poner en el lugar de siempre, pero no me he hecho del tiempo. En cuanto llegue a casa veré cómo me hago de una nueva cámara.

Como dije, ahora estoy visitando Amsterdam, idea que surgió medio improvisada. El 6 tengo pasaje a casa desde Frankfurt, por lo que tampoco puedo colgarme mucho.

Ahora a dormir, que me estoy cayendo del sueño...

On tour (stage 7): Madrid, España

Desde el viernes y hasta hace unas horas estuve en Madrid. Increíblemente, no será la ultima vez que pise Madrid en el corto plazo. Dentro de una semana tengo que pasar 10 horas nocturnas ahí, de camino a casa.

La estadía en la capital española fue particularmente social. La pasé con amigos, amigos de amigos, y otros niveles de indirección. Redescubrí la comida vegetariana gracias a Santiago y además cocinó y hospedó como solo los grandes anfitriones saben hacerlo.

Pero claro, tanta sociabilidad acortó las noches y llegué realmente cansado a la noche del domingo. Así fue como me quedé dormido el lunes y por poco no llego al aeropuerto a tiempo para irme a Viena. Por suerte, llegué con lo justo.

El único traspié fue desencontrarse con los Debianitas ibéricos (Holger, Amaya, Agi, etc) ya que los horarios del transporte de fin de semana me jugaron una mala pasada y llegué muy tarde. Tenía muchísimas ganas de verlos... una verdadera lástima.

BTW, me encontraba intentado reservar una cama en este hostel de Viena cuando, a la hora de pagar el adelanto, algo me dijo que podía ser peligroso hacerlo... adivina qué? :)

the root of all mistake: the overgeneralization

Yes, it's me again with this DSA-1571 exploitation issue. The discovery, explanation and exploitation of the bug is now part of my final coursework for my postgraduate degree career. So, yes... sorry.

Some weeks ago I started suspecting about the attack to PFS in SSL with EDH. The key point is: the key space is dependent of the PRNG state. The bug affects the initialization of the PRNG, but the random string has not a pattern by it self. If you ask for many random numbers to the PRNG, you gonna get numbers that differ among them, since they are the output of a hash function of them self. So each random number depends on, besides the PID, the state of the PRNG pool in the moment (in other words, amount of bytes that you already pull from the PRNG pool before)

The explained attack was based in a fixed list of private exponents (which are selected randomly during the DHE handshake), presupposing that all the application call RAND_bytes() the same number of times before get it. To make the list of exponent I ran the openssl s_client with all the possible PIDs, hoping that all the applications behaves the same way.

After more tests I notice that that was an overgeneralization. The proof is in the pudding: wget and cURL, two simple CLI file retrievers, gets different exponent between them, even running with the same PID.

I was working on this when I accidentally found a really nice Eric Rescorla's post which is deeply related with this. The post goes further and analyzes the interaction between how Apache forks off and how it generates SSL handshakes.

So, I made lists of secret exponents for wget, curl, openssl s_client and openssl s_server with a modification version of libssl (appling this messy patch) and running scripts like this:

for i in $(seq $((2**15)));
do
  export MAGICPID=$i;
  LD_LIBRARY_PATH="openssl.broken/" LD_PRELOAD="./getpid.so" \
     wget --no-check-certificate https://localhost/ -q  -O /dev/null ;
  echo $i ;
done

As you can see, I used the HD Moore's GetPID faker shared library and a normal local Apache with mod_ssl. The broken libssl (which is in .openssl.broken/) store up in /tmp/data.key a csv with command name, PID and all the DH components (g, x, y and p).

But this way is farly unconfortable for others SSL deamon servers. Have you got any better idea?

snail mail

Después de varias semanas sin pisar casa (Grand Canyon, Black Hat, DefCon y DebConf) detrás de mi puerta hay correo (del tradicional) en cantidad inusual. De un tiempo a esta parte, el correo no electrónico decantó en una forma de hacer llegar facturas, recibos, muestras gratis y nada más. Los sentimientos en el siglo XXI ya van por otro lado. Sin embargo, esta carta fue distinta:



Se trata del número de Agosto de Linux Magazine. El lector observador notará que no está en inglés, ni en alemán, sino en neerlandés. Me la envió Koen Vervloesem, quien hace poco menos de 3 meses me solicitó vía correo (del electrónico) detalles sobre la falla dsa-1571.

Obviamente lo único que soy capaz de entender es mi propio nombre, pero lo que cuenta es la intención :). Gracias Koen por el detalle, se que entenderás este post tanto como yo la nota :P.

Y hablando de correo físicamente transportado (aunque sin relación con lo anterior, que fue totalmente gratis), uno se da cuenta que vive en las antípodas del mundo donde le gustaría estar cuando recibe facturas de encomienda como esta:


Bizarro... pero cruelmente real.

volviendo de Las Vegas

Es difícil describir la intensidad de los últimos días. Solo a modo de dar una idea, en la última semana hice 5 check-in, vi una veintena de charlas, dí dos y conocí a decenas de personas sumamente inteligentes.

Vamos a lo importante: nuestras charlas :P. Tengo la impresión que hicimos una actuación mas que respetable. En ambos casos nos desenvolvimos muy bien y, creo, con claridad. Mucha gente nos hizo comentarios muy positivos y los asistentes parecieron divertirse. Me siento sumamente contento por ello.

Además de esto, hay cinco millones de cosas más que contar, incluso algunas más importantes y divertidas. Pero trataré de realizar esa tarea durante el avión de regreso a casa. El cual sale en 5 horas, ya que en este momento son las 2am. Ahora estoy realmente cansado y necesito terminar de hacer mi valija...

Ah! Casi me olvido. Para los colgados de siempre que nunca se enteran de nada... las fotos (aunque aún sin comentarios descriptivos) están, casi todas, acá. Enjoy them.

Exploiting DSA-1571: How to break PFS in SSL with EDH

( I love acronyms :-D ) Tal vez quieras leer esto en español.

At this point, all of you should know and see how the H D Moore’s toys work. Those toys attack SSH public-key authentication using clone keys and online brute force.

Furthermore, many of you know that there are other effects produced by a biased PRNG besides this one.

Strangely, I could not find more of those toys exploiting these aspects. So, I would like to show you a Wireshark patch which attacks Perfect Forward Secrecy (PFS) provided by Ephemeral Diffie Hellman (EDH).

Introduction to EDH

Let’s put it in plain words (if you know what we are talking about, ignore this and jump to the next heading):
In an insecure communications channel the parties agree a common key to cipher their dialog. This is what happens in SSL (in most of the cases, depending on the cipher suite):

  • The server selects a random prime p and a generator g of the field Z*p (Let’s ignore the mathematical properties of these values). So, the components p and g are public.

  • The server picks a secret random number Xs and calculates Ys=gXs mod p. Ys is public and is sent to the client (just like p and g).
  • The client does something similar, selecting a secret random number Xc and calculating Yc=gXc mod p too. The client makes Yc public by sending it to the server.
  • The shared secret s is the public key of the other part to the exponential of the own private number, all in p modulus. That is, for the client s=YsXcmod p and for the server s=YcXsmod p.
  • With this shared secret the parties can encrypt all the following messages in a secure way.
  • In the Ephemeral Diffie Hellman (EDH), the private numbers are ruled out, so s is mathematically secure and nobody can obtain it even having access to one of the parties after the aforementioned handshake.

The “exploit”

If an eavesdropper can explore the complete private key space (the all possible numbers for Xc or Xs), he/she will be able to get access to the shared secret. With it all the communication can be deciphered. That’s what this patch can do.

A Wireshark with this patch and a list of possible private keys will try to brute force the share secret. If one of the parties is using the vulnerable OpenSSL package the communication is totally insecure and will be decrypted.

  • The patch for Wireshark 1.0.2 can be downloaded from here.

  • Debian packages with the patch applied can be found here.
  • This is a list of all 215 possible 64 and 128 bit DH private keys in systems vulnerable to the predictable OpenSSL PRNG described by DSA-1571.
  • An example of a pcap file can be found here (it was built with a vulnerable client and one of the Moore toys, a hacked getpid by running $ MAGICPID=101 LD_PRELOAD=‘getpid.so’ ./vulnerable-openssl/apps/openssl s_client -connect db.debian.org:443 )

The patch was submitted in order to be committed on the Wireshark trunk. There you can find the patch against the on-develop source revision 25765.

Issues that can be improved

We (the other developers and myself) detected few things to be improved. But we will do nothing for them. So, if you want to contribute with some code, start from these items and submit the patches to the Wireshark’s bugzilla:

  • When the packets are out-of-order the decipher with stop itself.

  • The brute force attack should run in a background process (and with a progres bar)
  • Check the length of the keys before trying to brute force them.
  • The patch also implements the display of public DH parameters in the packet tree. It’s incomplete.

Credits

Paolo Abeni <paolo.abeni at email.it>
Luciano Bello <luciano at debian.org>
Maximiliano Bertacchini <mbertacchini at citefa.gov.ar>

This work was partially supported by Si6 Labs at CITEFA, Argentina.

UPDATE Jul. 21st: See more and updated info here, especially this.

cartoon

Después de pasar más de un mes sin bloguear, uno siente la obligación de tener que hacerlo por una buena causa.

Y ésta me pareció que lo es. Durante mi periódica vuelta por el lado del mal me encuentro una simpática repercusión tardía del ‘Debian/OpenSSL debacle’, siempre desde su peculiar perspectiva el amigo Josemaricariño publicó:


click para agrandar
Una vez más, muchas gracias al maligno por el reconocimiento. Es raro verse en forma de cartoon :oP.

porqué el 'Debian/OpenSSL debacle' no afecta mi creencia de que Debian es el mejor OS del mundo

En estos días escuché cosas como “Seguramente provocaste la mayor migración de usuarios de la historia, ya nadie querrá usar Debian en sus vidas”. Otros párrafos sobre la vergüenza que caía sobre los desarrolladores, sobre nuestros procesos de calidad llovieron de a decenas en mi inbox.

Este tipo de cosas me hizo reflexionar. Y es esta reflexión la que me gustaría compartir con ustedes.

Hace un tiempo ya, cuando casi sin querer y por accidente me encontré con el problema, simplemente me negué a creerlo. No podía ser. Era tan trivial y estuvo ahí, frente a nuestras narices tanto tiempo... parecía ser evidente de que yo estaba haciendo algo mal. Tardé mucho en confirmarlo, y aún con la duda lo reporté.

Junto a mi reporte adjunté un parche ridículo, casi insultante. Consistía en:
-/*
- * Don’t add uninitialised data.
MD_Update(&m,buf,j);
-*/

Esto fue el día 5 de Mayo. Al día siguiente tenía una respuesta, con una clara dirección de trabajo. A los pocos días se me informaron la fecha en la que el DSA saldría. Todo fue tan expeditivo, tan admitido, sin subestimaciones, pero con un fuerte sentido de la responsabilidad. Me pareció de una brillante sensatez el desarrollo de dowkd.pl antes del anuncio.

El 14 de Mayo el usuario tenía todos los elementos para defenderse. El paquete openssh-blacklist resultó ser sumamente útil y fue un aliciente entre el caos generado.

En mi vida no he enviado muchos advisories grandes (es el primero que hago totalmente por mi cuenta). Pero me pregunto: ¿Qué hubiese pasado si un problema como este hubiese surgido en algún otro software de alguna empresa? ¿Qué hubiese pasado si, en vez de ser un desarrollador de Debian el descubridor fuese un empleado de esta compañía? El bug dejaría de ser un vergonzoso accidente para convertirse en un devaluador de acciones. La baja de ingresos por clientes perdidos podría hundir la empresa.

En esta caso la historia hubiese sido distinta.

Es por esto que creo que el modelo de software libre es bueno, y en particular Debian es bueno, porque no responde a presiones comerciales, porque no oculta sus problema y porque su prioridad es el usuario.

Sin duda, problemas en el software habrá siempre. Sin duda, este fue un problema de proporciones épicas. Sin duda, la confianza en Debian se ha visto afectada. Pero la lección está aprendida. Y Debian sigue siendo mi sistema operativo favorito.

Esto no es una justificación, sino una profunda opinión personal.

cryptographic apocalypse

Well, maybe I was a little noisy with my first DSA. I will try to be quieter next time :)

I think that many people are being very unfair with the OpenSSL’s maintainers. They made (and are making) a really good job. Was an accident, that things happens.

What we need is a real auditory process of the Debian specific patches. It’s hard, but it’s necessary.

MS Vista Social Club

Ayer volví de Santa Fe. Conocí mucha gente copada y de variados colores.

Ante todo, muchísimas gracias a Lucas Bonomo por el hospedaje, la comida y la guía turística. La pasé realmente bien.

En otro orden de cosas, me dí el gusto de haber conocido a Chema Alonso, el maligno. Estrictamente hablando, vi por primera vez a este dantesco personaje dos días antes, durante la charla Técnicas más utilizadas para atacar WebSites, Top Ten OWASP en Exactas. La versión corta es que se trata de un empecinado friki pro M$, aficionado a la seguridad, quien terminó haciéndose mundialmente conocido por sus dibujitos (los que muchas veces ridiculizan los más hondos valores del software libre) y que en estos días su única ocupación es pasearse por cada rincón del mundo asegurando que IE es una herramienta de hacking :P

En fin, un encanto de muchacho, con quien vale la pena discutir desapasionadamente y con argumentos. Él mismo me hizo y regaló el dibujo que acá publico y que, para su bronca, fue editado con GIMP :D