TDSL

¿Qué? ¿Yet another acrónimo ofensivo?

No, Test Driven Self Learning, esto es, utilizar TDD para aprender.

Al encarar la escritura de esto, busqué "test driven learning", que por supuesto trajo innumerables referencias, asi que no hay nada nuevo bajo el sol.



Ya me había cruzado con la idea en un curso de hibernate y otro de ruby, en los cual me daban los tests e implementaciones parciales y para hacer pasar los test, tenía que implementar el código y de paso aprender. Es realmente un buen método.



Ahora bien, ¿qué pasa cuando no existe el curso? Me hallo en la situación de tener que aprender un nuevo lenguaje, tecnología e incluso agregaría paradigma, sin tener a ninguna persona real o virtual conocida que me asista. Así que decidí ir generando yo mismo los tests, como si aprender no fuera el objetivo.

El proyecto tiene que ver con obtener contraseñas a partir de una base de datos. Veamos primero que es lo que podemos encontrar, como pueden estar almacenadas:

• En texto plano: listo, no hay nada más que hacer.
• Hasheada: se le ha aplicado una transformación tal que no sabemos la clave.
• Hasheada con salt: al método anterior se agrega un valor arbitrario y conocido, ya veremos para que.

Para entrar en contexto, el mecanismo de autenticación suele funcionar asi:

1. El usuario se identifica y provee su clave
2. Se busca al usuario en la base de datos
3. Se aplica una transformación a la clave y se controla que el resultado coincida con lo almacenado. Esta transformación puede ser nula, cuando se ha almacenado la clave en texto plano.

Contra un sistema de autenticación hay varios métodos de ataque, algunos son:

• Online: se prueban diversas claves hasta acertarle utilizando el sistema. Este puede detectar los intentos y bloquear o limitar el acceso.
• Ingeniería Social: se obtiene la clave directamente del usuario mediante algún tipo de engaño, que va desde tan sencillo como pedírsela directamente como hacerle entrar en un sitio falso.
• Offline: se obtiene la base de datos y se prueba en la tranquilidad del hogar.

El último método es el que más me interesa ahora, ya que de eso se trata el proyecto. Una suerte de framework para atacar offline eficientemente una base de datos y que eventualmente facilite un ataque personalizado.


Dado un par(usuario,hash), entonces el objetivo es recuperar la contraseña. Los pasos pueden ser:

1. Buscar hash en internet, si esto falla, continuar.
2. Determinar que tipo de hash es.
3. Determinar si y cual salt puede haber.
4. Reproducir el algoritmo que lo genera
5. Utilizar una lista de claves frecuentes, aplicar el algoritmo y ver si le pegamos.

(Para ser estricto, tras el paso 3 se podrían usar rainbow tables, pero eso lo dejamos para otro dia, ¿ok?)

Para el primer paso contamos con los buscadores. A mano he llegado a lograr que google me confunda con un bot y me tire un captcha. Esto no escala, pues aunque de 400 entradas que me restaban de un ataque de 800 pude recuperar 60, me llevó un par de horas, mias, no va.

¿Por qué, Charli, que sos tan basher no hiciste un for HASH in $(cut users.txt -d" " -f 3); do wget http://www.google.com/search?q=$HASH -O $HASH.html; done?

Pues lo hice, pero google me bloqueaba en la primera, supongo que por el user-agent. ¿Sabés que wget puede impersonar cualquier user-agent? Si, pero quería analizar bien los resultados y cuando llegue a 30 o 40, tras 200 intentos, ya fue. Igual iba a tener que inspeccionar los *.html de modo un tanto manual, otro dia será.

Para determinar el tipo de hash, aprovechamos el paso anterior, en alguna página donde hubo acierto va a decir que tipo es.

Si hubo salt involucrada la cosa se complica. Lo mejor es tener la base de datos, el código y la configuración, de ahi sale, sino... Ahora es el despues de "ya veremos para que".

Siempre se deben guardar las claves hasheadas utilizando salt

• Si no se hashea, se obtiene el 100% de las claves

• Si se hashea, se obtiene el 99% de las claves débiles como "123456", "maradona", "c@Rl05", "pablo1974", "bugzilla", "klingon", "marsupilami", "newyork", "Oberon". A fines prácticos cerca del %50 del total.

• Si se usa salt aunque esa salt caiga en manos del atacante, deshabilita buscar en internet y dificulta rainbow tables

Ok, voy a explicar que son rainbow tables: ¿recuerdan el quinto paso, el de probar las palabras del diccionario contra cada clave? Es algo parecido, pero en lugar de probar y tirar el resultado que no sirve, se generan y guardan todos los hashes de un set para cada algoritmo. El set esta generado por ejemplo por todas las palabras posibles de una a ocho letras combinación de "a-zA-Z0-9". Esto lleva mucho tiempo, ocupa mucho espacio pero luego permite recuperar muy rápido. Más detalles en la internet. Ah, ¿pero por qué un hash interfiere con rainbow tables? Si a tu tonta clave "123456" antes de hashearla le agregás "hola" tal que te quede "123456hola" ahora mide diez y no está en la rainbow table.

Si el atacante consigue la salt "hola", debe generar todas sus rainbow tables para esa salt. Esto es, debe generar las tablas para cada sitio que ataque. Si además le agregas una "salt local" (como yo la llamo en contraposición a la "salt global") tal que te quede "123456hola#{userid}", tiene que generar la rainbow table para cada usuario. Esto no imposibilita el ataque, pero lo dificulta. Si es la cuenta de alguien importante, mas vale que ponga una clave larga.


Tras el rant, sigamos con reproducir el algoritmo. Es bueno tener el código fuente. Ah, ¿dije algo obvio? Si no, un par (usuario, clave) conocido en la base para utilizar como referencia, para usar algorimos equivalentes quizas en otro lenguaje.

El problema es el último paso. En una ocasión, 1000 usuarios con un diccionario de 68.000.000 de claves calculo que me hubiera llevado dos dias. Dije "calculo" y ahi esta la clave de todo este asunto, pues como tenía 4+2 cores a mi disposición, de los cuales usé 3+1, pude paralelizar y me llevó medio dia. It's a bash of magic.

Ahora entra erlang en la ecuación.

No voy a repetir la marketinera introducción a erlang, podés leerla directamente de las fuentes. Tratándose erlang de un lenguaje orientado a la concurrencia y a ser distribuido, puede ser una buena elección, pero tengo que convertir mis scripts en bash, php, ruby y perl en algo coherente.

Comienzo con el de php, que lo que hace es convertir "hola" en "h01@", "h014", "h01A", "h01a", "h0|@", "h0|4", "h0|A", "h0|a", "h0L@", "h0L4", "h0LA", "h0La", "h0l@", "h0l4", "h0lA", "h0la", "h@1@", "h@14", "h@1A", "h@1a", "h@|@", "h@|4", "h@|A", "h@|a", "h@L@", "h@L4", "h@LA", "h@La", "h@l@", "h@l4", "h@lA", "h@la", "hO1@", "hO14", "hO1A", "hO1a", "hO|@", "hO|4", "hO|A", "hO|a", "hOL@", "hOL4", "hOLA", "hOLa", "hOl@", "hOl4", "hOlA", "hOla", "ho1@", "ho14", "ho1A", "ho1a", "ho|@", "ho|4", "ho|A", "ho|a", "hoL@", "hoL4", "hoLA", "hoLa", "hol@", "hol4", "holA", "hola", "H01@", "H014", "H01A", "H01a", "H0|@", "H0|4", "H0|A", "H0|a", "H0L@", "H0L4", "H0LA", "H0La", "H0l@", "H0l4", "H0lA", "H0la", "H@1@", "H@14", "H@1A", "H@1a", "H@|@", "H@|4", "H@|A", "H@|a", "H@L@", "H@L4", "H@LA", "H@La", "H@l@", "H@l4", "H@lA", "H@la", "HO1@", "HO14", "HO1A", "HO1a", "HO|@", "HO|4", "HO|A", "HO|a", "HOL@", "HOL4", "HOLA", "HOLa", "HOl@", "HOl4", "HOlA", "HOla", "Ho1@", "Ho14", "Ho1A", "Ho1a", "Ho|@", "Ho|4", "Ho|A", "Ho|a", "HoL@", "HoL4", "HoLA", "HoLa", "Hol@", "Hol4", "HolA", "Hola" y es llamado mediante un vulgar system/exec desde perl y ruby (bugzilla y redmine respectivamente).

Esta función que sorpresivamente se llama leet(), me costó bastante, ya que la solución es recursiva. ¡Qué bien! Erlang es funcional (o sea que todo se hace con recursividad), no debería ser tan terrible, ¿no?

Varios dias despues:

De modo colateral he hallado que erlang soluciona todas esas discusiones de como testear los métodos privados que asolan las listas de discusión ágiles de un modo muy sencillo.

La unidad de compilación es el módulo, que podría ser asi:

-module(cracker).

-export([leet/1]).

leet(Palabra) ->...

funcion_interna() -> ok.

otra_funcion_interna() -> ok.

Los más sagaces podrán inferir que desde afuera se puede acceder a leet/1 y no asi a las funciones internas. Salteemonos un paso y veamos el código que prueba esto:

-module(cracker_tests).

-include_lib("eunit/include/eunit.hrl").

leet_test()->?assertEqual(..,cracker:leet("hola")).

otro_test()->?asserEqual(ok,cracker:funcion_interna()).

¡No! ¡A los sagaces nos diste a entender que el módulo cracker_test no puede ver a las funciones que no han sido exportadas!

Es parcialmente verdad, si desde el interprete (erl), compilamos normal.

1> c("src/cracker").

{ok,cracker}
2> cracker:otra_funcion().
** exception error: undefined function cracker:otra_funcion/0


pero si pasamos la opción "export_all", vemos todo, testeamos todo.

3> c("src/cracker", [export_all]).

{ok,cracker}

4> cracker:otra_funcion().

ok



Sin tocar el código, sin agregar funciones,  sin afectar nuestra política de lo que es público y lo que es privado.

Sigo cuando logre implementar leet/1.

1hackparaloschicos 2

Baja concurrencia y bastante impuntual. De, según oí, 60 inscriptos, vino menos de la mitad, lo que me llama la atención ya que no era del todo gratis. Mientras esperábamos, Fernando Gont contó sus experiencias laborales en el puerto, sin desperdicio.

Quizás parte de la inconcurrencia se haya debido a que había a la misma hora una charla de continuidad de negocio en ADACSI

A beneficio de http://www.1hackparaloschicos.org 14 de Diciembre de 2011,Auditorio Universidad de Belgrano

IPv6: Historia, presente y futuro

IPv4 se está quedando sin direcciones, punto.

Existe CGN/LSN (Carrier Grade NAT/Large Scale NAT) que puede mitigar (y lo está haciendo en algunos lugares de Asia y Europa), pero como uno ya está haciendo NAT, puede traer problemas. Además está el asunto legal, se torna más complicado rastrear el origen de una conexión. Y el monetario, sale u$s 1M. En África y LAC (Latino América y Caribe, vayan aprendiendo siglas) aún quedan direcciones libres, asi que se puede llegar a zafar si IPv6 llega primero.

IPv6 no es más seguro que IPv4, no tiene mejor QoS. Ni siquiera es backward compatible. Lo que sí tiene es 96 bits más de direccionamiento, lo cual es MUCHO. Tambien esta soportado por casi todos los sistemas operativos. El problemas es que hay que reemplazar muchísimo equipamiento core.

Tambien existe una profunda inexperiencia, sobre todo frente a los 30 años de IPv4 y su falta de uso extendido hace que aún no se haya descubierto una parte considerable de las vulnerabilidades que seguramente tiene.

La performance puede ser mala tambien, pues suele estar implementado en software en lugar de hardware.

Y la etapa de transición es aún peor, pues conviven IPv4, IPv6 y los sistemas de adaptación.

Me imagino, aunque no es idea mia, que los proveedores de networking son los que frenan la implantación, pues el equipamiento lo van a vender igual, hoy o mañana. Pero los CGN no tienen sentido si nos vamos ya a IPv6. Primero te vendo NAT, luego IPv6.

Correo electrónico seguro y cifrado - Santiago Cavanna

Distinguió el cifrado de almacenamiento, de canal y de objetos circulando. En un canal encriptado entre dos servidores de mail el mail esta seguro en términos de integridad y confidencialidad, no? Pero si generamos un mail falso y lo metemos en ese canal...

Luego un poco de historia de utilización de cifrados, ligado al aspecto militar == negocios.

El ambiente actual es hostil y cada vez empeora, por lo cual no conviene intercambiar información importante (¿quién sabe cuál es importante y para quién?) por mail, chat o incluso teléfono.

¿Por qué cifrar correo si nunca me ha traido problemas no hacerlo? Bueno, hasta que te trae.

Como inicio de solución PGP o SMIME.

Agresores Sexuales - Identificación y aplicación de la técnica de perfilación criminal - Maria Laura Quiñones Urquiza

Pidió no grabar, filmar ni fotografiar la exposición. Yo, fiel a mis promesas, ni tomé notas, entiendo el porqué. Sólo voy a decir que CSI, L&O SVU no son del todo fantasía.

Vidas Reales, rastros digitales - Gustavo Daniel Presman

Expuso de privacidad y trazabilidad. Distinguió entre la información cedida voluntariamente y la "otra". Quedémos con la otra.

De como es bastante difícil borrar incluso en la propia computadora todo traza de actividad. Por ejemplo al borrar el historial de navegación, bien puede quedar en un archivo que es borrado por el sistema operativo, que bien puede no volver a escribirle nada encima y se torna recuperable.

Exif en fotos, tipo GPS e IP, que puede conducir a GeoIP. Marca cámara y serial number. Buen modo de rastrear un celular o cámara robado o perdido...

Mensajeria deja trazas en el archivos temporales.

USB, es posible obtener información de dispositivos ya desconectados, al menos en windows.

Propuso que además del log de ip/client de los ISP, se agregue el tráfico, esto es ip:port->ip:port, pero no de contenido.

Contó de saber de varios casos en que por mala conversión horaria de logs ha provocado que la policía hallane la casa equivocada. Brillante.







No me pude quedar a las otras dos charlas

Agiles 2011 dia 3

Hoy es el gran dia del open space, pero no es mi gran dia. Mi sesión de seguridad no ha sucitado ningún interés, asi que tengo que ver como meter la demo en otra.

Luego me hice una lista de las que me interesan, que eran ocho. Salieron cuatro, dos de ellas a la vez.

Primera sesión, propuesta por Nico Paez, acerca de colaboración académica. Su propuesta es hacer un equipo de trabajo con múltiples integrantes de varias facultades para resolver un trabajo práctico, una práctica de equipos distribuidos. Asistieron personas de La Plata, Paraguay, Chile, Perú, Tucumán, BA, Trelew y Salta. Dada mi no docencia, nada he podido aportar. Quedó ofrecida mi magra ayuda posterior.


Segunda sesión, por Sergio Gianazza, acerca de las raices ágiles, comenzando por el manifiesto, pasando por los principios y otras cosas similares.

Enunció lo de los estados: miedo, tristeza, enojo y contento, con su potenciador, la pasión.

Miedo + pasión: coraje
Tristeza + pasión: sensibilidad
Enojo + pasión: (no recuerdo)
Contento + pasión: (no recuerdo)

Yo lo veo más así:

Miedo + pasión: huida desesperada
Tristeza + pasión: suicidio
Enojo + pasión: asesinato
Contento + pasión: lujuria y lucha en el barro.

Pero es sólo un punto de vista.

Luego mencionó algo de la motivación, tipo que desde el big bang hasta 1600 era la reproducción (o el sexo, no recuerdo), luego el dinero y recientemente algo distinto. Le pregunté si lo que habia cambiado era la motivación o la percepción de la motivación y me parece que no me entendió o que si pero yo no entendí su respuesta, asi que agoté el diálogo con transparencia e integridad: "Sergio, me parece que esa idea es una tremenda gansada, pero tenemos meses por delante para deliverar" (es que vamos a renunciar a tc y poner un delivery, obvio).

Tercera sesión: nada interesante, me quedé en el bar configurando mi Fake Access Point, con un 95% de éxito:

Internet -> universidad de palermo -> host -> virtual con fake AP -> víctima
Logré que la víctima navegue un sitio en el host, pero no pude salir a Internet, quizas haya alguna protección en up, otro dia pruebo en casa.

Cuarta sesión: Equipos distribuidos. Gente de Ecuador, Bolivia, Perú y Argentina. Usar audio y video todo lo posible, pero grabarlos o generar minutas, ya que las cuentas claras mantienen la amistad.

Unos tienen video hd + proyector mas QoS.

Otros, estando a 15 cuadras un sistema pago. Por asuntos contractuales no pueden trabajar juntos los de dev y qa (distintas consultoras). Tienen las camaras apuntando a los pizarrones. El que necesita golpea la pantalla como si fuera un ventana y del otro lado suena.

Otro recurso: escritorios compartidos.

Conclusión: mucho peso en la comunicación.


Cierre a cargo de Juan Gabardini: mencionó que el generalista típico de los equipos pequeños no tiene un cv presentable (si, sé programar, pero administro los servidores y hago de mesa de ayudas... y tambien soy team leader), pero calza muy bien en agile. Luego, espero citar bien, una frase para enmarcar "en las empresas grandes se arman y desarman equipos por proyecto, que es un forma de locura"

Decano ingeniería UP: decano de universidad privada? prejuzgué que debía ser un bandido latoso. Quizas lo era, pero me sorprendió su lucidez, chau UBA, me voy con los oligarcas de la UP.

Dijo que los proyectos [de software] a diez años no son posibles. Agrego yo que la vorágine actual (que viene de hace no menos de una década), impide hacer nada a largo plazo desde el punto de vista tecnológico/táctico. Pero me parece que eso afecta a sólo un tipo de negocios. Hacer el soft de un barco, un avión, un sistema de tráfico, un sistema operativo, sigue siendo una tarea a mediano/largo plazo y hay que convivir con tener ciertas partes obsoletas al salir a producción.

Es un fenómeno del que ya habia leido en el espectacular libro "Los nuevos alquimistas : Silicon Valley y la revolución microelectrónica" de Dirk Hanson (1984). Comenta como al salir un avión de combate de la fábrica, la electrónica es obsoleta, dado que el tiempo que lleva diseñar un avión de ese tipo es de 10 a 15 años. No puedo recomendar que lean el libro en parte por que quién se lee un libro de tecnología de hace 25 años y en parte por que, ¿dónde lo van a encontrar, hijos de google?

En el 2009, le pregunté al autor: have you ever considered updating it?


Thanks for the kind note. At one time, I had considered updating the book to tell the story of the birth of the personal PC, as a coda to the story of the transistor on a chip.

However, as often happens, my publisher, Little, Brown and Co., chose not to keep the book in print. And you can't update an out-of-print book.

But now that I have jumped into the publish-on-demand world of BookSurge and Amazon, this aging alchemist might consider the project again if time and circumstance allow.

Regards,
Dirk

Ya que me estoy yendo tan por las ramas, hace rato que para el asunto del hardware obsoleto existen los FPGA. Para el caso de los aviones supongo que deben trabajar con módulos reemplazables. El avión sale de la fábrica con un cierto hardware que no es el diseñado originalmente, sino un subproyecto que arranca mas recientemente. No bien está el nuevo hardware, se reemplaza durante el tiempo de vida del avión varias veces, me imagino.

Pero acabo de recordar, aunque no de donde lo saqué, que para sistemas científicos satelitales, creo, se usan arquitecturas obsoletas ya que cumplen con lo necesario y son mucho mas conocidas que las que están en la cresta de la ola, lo cual a mi me suena razonable.

En el soft no existe tal problema, ya que el soft es actualizable, jeje. Pero ya es tarde y no pienso claro, esto es tema a desarrollar.

Agiles 2011 dia 2

Hoy no perdí el anotador, pero me olvidé la fuente, asi que cargué un alargador de seis metros con zapatilla de cuatro tomas con térmica de mas de un kilo en vano.

En lugar de atender a la key note, me puse a preparar una demo para proponer mañana en la open space. Tengo que montar un access point trucho para mostrar los inconvenientes de conectarse a redes desconocidas para integrantes itinerantes de equipos. Tiene que ser algo corto y efectivo, menos de 10 minutos para que haya tiempo para el posterior debate.

Primera charla, Hernán Wilkinson sobre los diez mandamientos de tdd, que resultaron ser mas. Transcribo y decoro mis notas:

Sacar los tests implícitos y efímeros de la cabeza del dev. Hacerlos explícitos, persistentes, repetibles y automatizables.

El buen programador lo es si y sólo si es buen tester.

La tabla de management:

Tdd es un cambio cultural, no automático, no ocurre por si mismo. Hay que proveer el entorno. Pair Programming ayuda. LLeva tiempo, que pata a mediano plazo. Mientras da una detección temprana de errores. No hay que abandonarlo por eventuales retrasos, o al menos hay que hacer explícita la desición. Tdd no es infalible. 100% cobertura no es posible ni tiene sentido. 60 a 80%.

Para medir la calidad de los test Mutation Testing: se invierten las relaciones de cada if y se ejecutan los test. Si no fallan, hay un problema.

No reemplazar QA por TDD. No mezclar Jr con Sr, si Jr con SSr y SSr con Sr. Para lograr el estado "test infected", puede llevar 3 a 4 meses.

Tabla de dev:

Primero se escribe el test.
Cada test debe tener un assert.
Un test a la ves (si estás muy creativo, el resto a una todo list afuera).
TDD no equivale a Unit Testing.
El nombre es el QUE, no el COMO y debe ser tan (ridículamente) largo como sea necesario.
En un test debe haber un solo caso.
No testear dos veces lo mismo.
Los test son otro sistema, keep clean.
No testear desde las interfaces, hacerlo desde el modelo.
No usar DB relacionales (al testear) por performance y por contaminación al modelo de objetos. Esto induce desacoplamiento.
No usar sistemas externos.
No hay que mockear el modelo.
TDD no implica buen diseño.
No preocuparse por la performance al comienzo.

Fin charla.


Luego me salteé el siguiente bloque para intentar levantar el fake AP. Me parece que lo logré, al menos Sergio lo vió. Pero no pude comprobar que funcionara, me quedé sin power. Termino de escribir esto y le doy.

La otra propuesta de sesión parte de que tengo un análisis FODA/SWOT de seguridad para una empresa de software que lleva a una colisión directa y brutal con el principio ágile de "transparencia".


Story Planning con Jeff Patton.

No voy a relatar lo que fue. Me desbordó totalmente, me va a llevar dias de trabajo subconciente asimilar toda la información. O un par de horas terminar de olvidar todo. Afortunadamente Sergio tiene algo parecido para dictar.

Buenas noches.

Agiles 2011 dia 1

Lamentablemente he perdido mi anotador. Como le puse mi nombre, quizas lo recupere mañana, en cuyo caso editaré esto un poco.

Habló un tal Jeff Patton (http://lmgtfy.com/?q=jeff%20patton pero no se sientan lucky, pues hay otro jeff patton que sale primero).

Fui entonces a las sesión de unos brasileños que dijeron sim, sim cuando les dije fala devagar, pero no devagaron nada. Analizaron los motivos por los cuales se hacen branches y por que evitarlos.

Luego, Jorge Silva y Hernán Wilkinson mostraron las bondades de los lenguajes metacirculares y los closures, señalando la relación entre el lenguaje y el pensamiento. Como un lenguaje con esas bondades, permite pensar en cosas que en otros no. Si no me creen, miren una página de assembler y traten de pensar en interfaces.

Uh, me tocó a mi. Gracias a la tarea de apuntador de Sergio Gianazza (Teracode y http://www.dosideas.com, aunque este último no me consta, ya que no encuentro entradas recientes) salió mejor que en ninguna otra ocasión. Expuse un sencillo ejercicio de TDD guiado por el descubrimiento de vulnerabilidades en un sencillo sistema web que permite hacer posts. Es una versión mejorada de lo presentado en agile open sec 2010 y en TechTalks en Teracode. La diferencia es que esta vez logré encontrarle el flujo de requerimiento/vulnerabilidad -> creación test -> fail -> corrección -> pass. Me quedaron incluso unos minutos libres, pero no lo suficiente para la segunda vuelta donde expongo path traversal.

Almuerzo: entre otras cosas habían unas ciruelas envueltas en jamón o panceta de aspecto repulsivo, pero me comí no menos de seis, estaban deliciosas (perdón por el offtopic, pero realmente estaban buenas).

Me quería meter en el workshop de Jeff, pero habiendo cupo y llegando un minuto antes de que empezara, no, no, imposible, quizas mañana. Caí entonces en un Refactoring Golf a cargo de unos peruanos. Era un ejercicio diabólico en el que habia que, ¡sorpresa!, refactorizar código de una versión a otra evitando cortar y pegar o escribir, priorizando las capacidades de refactoring de eclipse. Esta bueno para hacer en otra ocasión, pero con más tiempo.

Finalmente asistí a algo de User Stories a cargo de Katia Sullivan. Muy clara y divertida. Además me regaló unas Planning Poker Chips, muy cool, parecen oreos.

Para compensar la pobreza de este reporte (por el extravío de mi anotador, que tienen mi nombre, si alguien lo encuentra...) la nota de color: la renuncia de JP produce estupor mientras se propaga como voraz incendio. Es que no esperaba perder el anotador, obvio, entonces no hice el esfuerzo de recordar y no le hago justicia a ninguna exposición.

Ekoparty dia 3

Ha mejorado mucho la puntualidad. Asi que me perdí la bienvenida y un pedacito de Gasto Público Bahiense a cargo de Manuel Aristarán. Mencionó una herramienta útil para scrapping (interfacing con sitios web) llamada... Scrapy.

Tiene montado un sitio que... scrappea y normaliza datos de compras de la municipalidad.

El segundo, Tom Riddley, no, Ritter hablo de ataques contra hashes utilizando Boinc, o sea, de modo distribuido. Parece que llegó a montar OCHO mil nodos en amazon para hacer en una hora algo que normalmente lleva semanas o meses.

Deprimido y solitario (deprimido por lo solitario) me paseaba cuando sorprendentemente reconocí entre la multitud a Martín Tartarelli, de fama OWASP. Inmediatamente se nos reunió Nahuel Grisolía de fama Bonsai, quien gentilmente me ha canjeado o regalado un detector de movimientos (que anda), un lcd de 16x2 (que anda) y un pic no se cuanto (que no sé si anda aun). Esto me llevó a conocer por fin en persona a Andres Riancho, de fama Bonsai y w3af, con quien ya tenía vínculos ciberespaciales. Asi que continué mi marcha alegre por mi breve momento farandulero.

Luego un alemán Tobi Mueller mostró USB fuzzing with qemu, muy interesante, maldición, otra idea que venía rumiando, la de atacar drivers de usb mediante dispositivos usb "simulados". Yo lo venía pensando via arduino/teensy (pensando, no he hecho nada, carezco del conocimiento y tiempo)(pensando, no he hecho nada, carezco del conocimiento y tiempo)  y él ya lo tiene casi hecho mediante programas.

Qemu es instruido en redireccionar todo el IO usb via pipes a un programa, que hace la magia, desde monitorear e injectar con dispositivos reales a directamente registrarse como un dispositivo.

Este muchacho tuvo muchos problemas con las demos, de hecho ninguna le salió, pero previsoramente habia grabado y pudo al menos mostrar eso.

A continuación vino un simpático español Chema Alonso, extremadamente divertido, que accedió a servidores citrix/rdp/ts en vivo, salvo uno que tenía grabado.

No habiendo escarmentado el lunes, volví a lockpicking y volví a fallar con impressing de 3 pines. Más conciente de mis limitaciones, me pasé a uno de 2 y LO LOGRÉ, por fin me fue bien en algo!!!

Mi lista de deudas crece y se depura:

Analisis forense: uno de estos dias.
Antena biquad: uno de estos dias.
Subir y analizar resultados del wardriving: uno de estos dias.
(dead) desafío core
(dead) desafío eset
(NEW!) Antena biquad nuevo modelo que he ideado: uno de estos dias.
(NEW!) 3 pines: ahi voy...

Bien, 3 pines logrado. Pero en el afán perfeccionista me pasé y la arruiné, no importa, durante un momento la cerradura abrió, no soy tan loser.

OSSI(Open Source Satellite Initiative, o algo así): un artista, me perdí el comienzo, que se armó un satélite de 10x10x10, 1kg3, con arduino y en medio año se lo ponen en órbita.

Dos rusos mal, como los mafiosos de las películas, investigadores de eset mostraron unos rootkits que atacan via mbr, asi que otra vez siglas locas.

Luis Miras: baseband en smartphones, para los que me miraron raro cuando les conté que en un evento de arm habian dicho que los iphone tienen como once cores. Es un core que controla el hardware y provee entre otras cosas protocolos de comunicaciones, usa un realtime os, nucleus en el caso de iphone, o sea que el iphone corre al menos dos sistemas operativos a la vez, coman! Se comunican via shared memory y... AT commands!

Nitroman: un zanquista con ropa led, pistolas laser, fuegos artificiales y un lanza algo frío, muy frío...



B.E.A.S.T.: interesante ataque, pero no tan terrible como se escuchaba en los pasillos, pronosticaban el fin del mundo. Permite capturar los cookies protegidos por TLS, mostraron un ataque en vivo contra un navegante de paypal.


Y esto es todo, amig@s. Podría ir a una buenísima fiesta en Quintana y Callao, que top!  a la cama. En unos días haré el postmortem de todo esto, cuando termine de asimilar.

Ekoparty dia 2

Llegué tarde pero no importa, esto no se caracteriza por la puntualidad. Mientras, puedo mencionar que si para el taller de antenas de ayer hubiesen pedido que los asistentes que pudieran llevaran un soldador y un par de cosas mas, todo hubiera sido mejor. Pero me pregunto si las personas que tienen esas herramientas asisten a un taller tan básico.

Desde ayer hay unos CTFs aparte del de ekoparty. Uno de core y otro de eset. El de core es, dado un código fuente c# manipular el sistema que lo ejecuta para conseguir puntos. Ya conseguí 18 y 20 puntos en dos cuentas separadas. Los primeros mediante el sencillo shoulder surfing, los segundos levantando una tarjeta tirada en una mesa. En ese caso no estoy seguro si ya tenia los 20 o los conseguí yo de algún modo esquivo aun para mi. Asi que con análisis de código y reverse engineering parece que no me voy a ganar la vida.

El de eset es levantar un qr e ir a un link donde hay que forzar una autenticación. Aun no pude interpretar el qr, parece que el hacking no es lo mio.

Además hay otro desde hoy de análisis forense, que es encontrar una persona que desapareció dos dias antes de graduarse, dado un dump de su smartphone hallado en una casa de empeños, basado en un caso real en Colombia. Hay que revisar UN GIGA de cosas, como sqlites, plists, caches para mañana a las 11:am, me parece que tampoco el análisis forense es mi futuro.


Asi que esta es mi lista de tareas para la semana que viene:

Terminar la antena
Efectuar el análisis forense
Romper el desafío de core
Descifrar el qr y forzar la autenticación de eset

Estos dos últimos los podria hacer ahora a la noche... mejor me voy a dormir? Ya son las 21:30, estoy muerto, ir a estos lugares es peor que trabajar. Todo se retrasó tanto que me perdí las tres ultimas presentaciones.

Estuvo un man de snort (google snort asi se entiende el resto), James Kirk, no, mentira, Alex Kirk, con un par de ideas interesantes, como:

buscar verbos de irc en los comienzos de los paquetes en todos los puertos,
examinar los user-agents
buscar filenames en POSTs
y tener en cuenta que usando application/octect-stream se puede pasar cualquier cosa sin ser detectado.

Antes estuvo Cesar Cerradio, que señaló otra vez la ausencia en internet como presencia (no se entiende? pregunte!).

Luego de modo maravilloso, utilizando las paginas de diversas entidades obtuvo una cantidad infernal de información de una persona famosa, tipo documento, domicilios, teléfonos, cuentas de bancos, lugares donde compra online, reservas de pasajes. La esencia del asunto? No hay que hacer wizards para registrar.


Pero mucho mejor el taller de lockpicking, si conseguís llaves vírgenes con un poco de práctica podes abrir cerraduras de tambor con muy poca interacción con la cerradura. Los tipos que se dedican lo hacen en un par de minutos en total. Lo intenté y fallé miserablemente, no pude hacer la marca ni siquiera donde va el cosito cuyo nombre en español no sé y en inglés no recuerdo. Parece que tampoco me voy a ganar la vida abriendo cerraduras ni recordando cosas.

Los tipos estos venden un kit para el lockpicking tradicional a $100, pero en casa ya no me autorizan el gasto. La lima especial para el otro método http://www.youtube.com/watch?v=Bj9KEmLWRek, impressionning, $150.

No logro conectarme a la wifi, merezco estar acá.

Marcos Nieto mostró como utilizando un proxy con capacidad de reproducir las capturas, se puede hacer dinero virtual en juegos de FB. Lo interesante es que ese dinero virtual se transforma via eBay en dinero REAL.

Core: muy aclamados, "y ahora para levantar el nivel", un tanto soberbio. Por suerte hace un par de semanas terminé de leer el libro de rootkits, si no me hubiese quedado dormido en la parte de IVT, GDT, IDT. Bueno, un poquito cabeceé. Uno atras mio al terminar dijo "no entendí ni un 15% de lo dicho". Expusieron un rootkit que via mbr arranca antes que el sistema operativo y utilizando del flag de debugging intercepta toda la carga tanto de windows, como bsd y linux. Varios ejemplos muy vistosos. Me quedó una sensación de campana de gauss deformadísima, como que unos pocos entendieron mucho y el resto... Voy a ver si mañana indago, es que ya me estoy haciendo amiguitos.

Ekoparty dia 1

Afortunadamente fuí reconocido por un ex docente que tuve en eci2011 (mpi), de Intel Córdoba, que me presentó a sus compañeros, así que no quedé como un nerd solitario más y me brindó la posibilidad de poder todos mis pésimos chistes habituales ante una audiencia fresca, como el de la reencarnación. Eso si, no bien me separé de ellos me confundí con el resto de la gilada sin desentonar.

La tasa femenina es aún más baja que lo normal en informática, lo cual confirma mis sospechas de que las mujeres son más inteligentes que los hombres.

La mayor parte de la concurrencia se ha concentrado a la sombra, nada necesito decir al respecto.

No parece haber mucha gente. Intenté contarlos varias veces pero me distraje o aburrí antes de terminar.

No debí haber traido el libro de BackTrack 4, ya que es pesado, es creepy ver a alguien acá leyendo un libro en papel y fundamentalmente ya hace mas de dos meses que salio BackTrack 5.

El sol está quemando mucho, quizas tenian razón en ponerse a la sombra.

Hay muy pocas personas de traje y son bastante altos.

No he traido nada con rfid como el monedero o la tarjeta de acceso, pero quizas fué exagerado.


Hay tres recursos para el nombre en la credencial:

1) Guardarla en el bolsillo: puede producir problemas logísticos y llama la atención.

2) Darla vuelta: es extremadamente llamativo, "hey, miren! no quiero que lean mi nombre!!"


3) El mio, poner la tarjetita que tiene el nombre detrás del programa. Es práctico y efectivo y sería la que menos llama la atención si no fuera por que estoy escribiendo en un cuaderno A4.

Acto de apertura. Gerardo Richarte expuso sobre tecnología y privacidad. Qué va a pasar con todos datos que se recopilan dentro de 15 años? Participar en la redes sociales es entregar esa información gratis. Y si no querés, es en vano, ya que una vez que tus amigos te invitan, esa ausencia no hace diferencia, la red sabe quien sos. Además de como otras personas pueden aportar información tuya, como cuando hacen backup de sus agendas, donde vos estás.

Contó de como con tus llamadas top, la telefónica sabe quien sos, ya que una vez que tenés un perfil, cambias de aparato y chip, sin relación con vos y a la semana el perfil te identifica.

De como incluso personas capacitadas como el cracker de la ps3, a quien se le escapó una foto con geo location en el exif, siendo prófugo de la justicia.

Y una idea interesante, que las personas no son clientes de las redes sociales, sino materia prima.

Talleres: fuí al de armado de antenas bicuad, pero quizás debí haber ido a client side usb o la de la distro de OWASP o incluso a la de análisis forense.

Por suerte el audio de AF se está difundiendo al mismo espacio de antenas y, nada, justo cortaron el audio. Bueno, asistí a una cuarta parte.

Me crucé con un muchacho de GNU Radio, que había conocido en un taller de buffer overflow de lvlrun un sábado. Medio que no me ubicaba (bravo! alguien peor que yo. Al muchacho de Intel le dije "de la iso27k?", "no", me dice, "de la eci" y yo pensé "fue de librerías de seguridad" hasta que al fin logré reconocerlo, casi un minuto), hasta que le señalé que yo había sido el que llevó cindor mientras él cerveza.

El taller fue correcto, pero evidentemente no lo habia ensayado. Igual no me quejo. Lo dirigió un Federico de... (cuando recuerde completo)

Por supuesto que la antena no la terminé, ese alambre barnizado es imposible de soldar, hasta que le sacás el barniz, claro. Esto me demoró y casi me pierdo el wardriving.

Este lo dictaba Juan Pablo (algo, luego lo busco). Afortunadamente ya lo tenía visto, pues tenia una regla de filtrado: si kismet te anda, subís al micro. A mi medio que no me andubo y le dije si podía ir con airodump-ng, ok, subí.

Horrible musica brasileña de fiesta alternada con otra que ya he mencionado en otro lugar, en un micro para paseo de niños, donde no entrabamos ni a palos, cerveza. Justo cuando subía cambié la placa alfa de 2w por una pedorra rtl8187b y funcionó ok. Luego Juan Pablo me prestó un gps. Hasta que lo hice funcionar me perdí toda la zona de Once y centro, o sea que tengo caprtura sin gps de esa zona. Recién en puerto madero tengo captura con gps. Adivinen que universidad católica tiene los APs abiertos?


El micro estaba para el asalto, 40 notebooks al menos, dos camaras digitales profesionales, 39 smartphones (el mío es dumbphone, windows 6.5). Atras mio había uno con una notebook de OCHO cores y OCHO mil dólares. Además hubieron OCHO mil redes detectadas, quinieleros alerta.

Les debo las fotos de la credencial/programa, de la pulsera identificatoria y la captura de kismet

Más experiencia en juego UL

Siguiendo la experiencia de Juego UL: experiencias, empalmando con lo que dice Juan Gabardini en Como organicé un curso de Scrum de dos días, "Funcionó bien, pero por como la hice (una sola imágen recorriendo entre quince personas), perdió punch. Probablemente debería haber hecho circular simultáneamente dos conjunto de tarjetas." y en el marco de la quincena Agile de Tech Talks en Teracode donde trabajo, donde se hizo el juego "UL", puedo confirmar que:

• Es una actividad no grupal. Uno hace, el resto espera, se aburre y dispersa.
• Mejor jugar en momentos muertos de otras actividades, como por ejemplo cuando los clientes o los desarrolladores de "Spec Writer" salen del espacio.
• Para reducir la pérdida de impulso:

• utilizar varios blocks con distintos motivos, claro,
• tener algún tema de charla preparado interesante o
• al menos unos chistes

Juego UL: experiencias

Otros resultados del juego

Grupo de implantación agile de Teracode La consigna fué "una letra, unos garabatos e incrementar el contador". Se trata de personas muy en el tema, asi que no me sorprende la poca variación. Cinco personas.

---

Comedor Teracode A6

Comedor de Teracode Dos rondas simultáneas con tarjetas A5 y A6 con 14 y 18 participantes respectivamente. Algunas personas participaron de ambas rondas. Los dos tamaños se utilizaron para medir si el espacio extra estimulaba el movimiento, pero lamentablemente los ejercicios no eran equivalentes, ya que el A5 tenia figuras fácilmente reconocibles que como se puede apreciar tardaron más en romperse. En cambio, A6 fué una fiesta. La consigna fue "una letra, unos garabatos,  una figura geométrica e incrementar el contador". Me resulta interesante en el caso de A5 que la rotura de la nube con el rayo comenzó en la persona 15 (la catorce es la que tiene el rayo bien marcado), que era la única persona no técnica que participaba.  Supongo que con dos o tres personas mas se convertía en una bota de papá noel.

Comedor Teracode A5

---

Conclusiones

• Diez parece ser un número mímino para garantizar la efectividad del juego.
• Aunque menos espectacular, funciona con cinco.
• Más de veinte es demasiado.
• Dado que es por turnos y lleva tiempo, no está bueno que sea de dedicación exclusiva. 
• Mejor explicarlo y mientras se juega hacer otra actividad.
• O como hicimos en Rosario: en el marco de otro juego donde el grupo se partía en dos, se le dió el juego a la mitad que estaba libre.
• Sin ofender a nadie, jeje, con grupos más calificados, la rotura es menor, considerar eso en relación a la cantidad de jugadores.
• La rotura es mayor y más veloz cuando no hay figuras o símbolos reconocibles.
• La enunciación del significado de las figuras, como es razonable esperar y es el objetivo de este juego, ayuda a conservarlas.

Gracias a Greta Luna por scannear y pegotear las imágenes.
http://www.lanilunatejidos.blogspot.com/
http://gretaluna.blogspot.com/

Juego agile: UL (Ubiquitous Language)

El juego

Se utiliza un block de hojas a5 (una a4 cortada por las mitades) o similar. 
En la primera se dibuja una letra, un número, un símbolo distorsionado y un par de huevadas más, por ejemplo:

 Luego, se le da la consigna al grupo, que consiste en:

• Evite ver el trabajo de las otras personas.
• Reciba el block con la tarjeta dibujada.
• Copie sin calcar la letra y los dibujos.
• Arriba a la derecha hay un número, recuérdelo.
• Al transcribirlo, auméntelo en uno
• Quédese con la tarjeta que recibió.
• Pase su dibujo con el block a la siguiente persona.

Cuando termina la ronda, se retiran los dibujos y se exhiben en orden para mostrar los resultados.

Es extremadamente importante recalcar y repetir muchas veces durante el transcurso del juego "la letra y los dibujos" ya que es la esencia del juego. A mi me resulta simple, quizas por ser programador, pero mi experiencia es que hay que explicar el juego varias veces, paciencia. Si alguien prueba este juego y encuentra una manera mejor de expresar el procedimiento, avíseme, por favor. De todos modos insisto en insistir "letra vs dibujo".


Es importante no mencionar el nombre completo del juego, para que los que conocen DDD no estén alertados.


Resultados


Se muestra que de existir un acuerdo acerca del significado de los dibujos, se distorsionan menos al comunicarlos. Dependiendo de los resultados, se puede mostrar la convergencia hacia conceptos.


Orígenes

Es basicamente el famoso teléfono descompuesto, pero para mi fue una relación retrospectiva, ya que, aunque sin duda ese juego forma parte del humus de mi mente, no llegué desde ahi. Estaba de colaborador ad-honorem de computación en fiuba, que es una introducción a la programación para estudiantes de ingeniería no informática, cuando pensé en como transmitirles la diferencia entre digital y analógico, como un mensaje digital se puede reconstruir pese al ruido y como el analógico se degrada irreversiblemente.

Descripción


La clave del asunto es que aunque son varias entidades, a la primera la identificamos como letra, de modo tal que quien hace la copia reconoce la letra y la transcribe como tal. El segundo, como es un número, es reconocido por algunos como tal pero otros no, asi que puede distorsionarse o no. El resto de los garabatos muere instantáneamente, no hay manera de que llegue al final de la ronda.

El objetivo es mostrar como el tener código común, en este caso el determinar que el primer dibujo es una letra, permite que los mensajes se distorsionen menos. Un punto para el "ubiquitous language" de Evans,  de ahi el nombre "UL".



Experiencia Computación FIUBA 2009

El objetivo en este caso era mostrar como la información analógica, el dibujo, se degrada irremediablemente en cada paso, mientras la digital, al tener una referencia se puede corregir indefinidamente. Esto es sin considerar ruidos mayores, para los cuales están los códigos autocorrectores y toda la lata.

Antes hice una prueba con cinco integrantes en mi trabajo, en la Secretaría de Educación del GCBA pero como eran todos programadores, sólo me aportó la demostración de que funcionaba.

En clase tuve que hacer dos rondas, ya que la consigna no fue comprendida y cada integrante pasó el original en lugar de su copia, asi que se redujo a unos ocho participantes pues ya me habia quedado sin tiempo. Esto me permitió percibir que hay que explicar muchas veces la consigna y de paso aprovechar en recalcar letra/dibujo.


Fue interesante que la letra "A" se convirtió en "a", en el resto no hubo sorpresas.

Experiencia Agile Open Rosario 2011

Lo presenté en sociedad agile en este evento con los resultados esperados y más.


Lo probé en dos grupos, de diez y quince integrantes, con una A, en 1, un signo + con una linea redondeada cerrando en tercer cuadrante, una tormenta en un plato arriba de una espiral y el contador arriba a la derecha encerrado en un círculo. Ah, justo lo que hay en la imagen más arriba, es que estoy escribiendo en orden distinto al que estás viendo.


La letra sobrevivió intacta. El número en un caso desapareció, impresionante. De los restantes, el + se convirtió en una gama y en una jota, la espiral en una G y el otro no recuerdo, perdón, no me llevé las tarjetas para scannearlas. ¿Se vé como sigue activo el juego? Me parece que en un grupo desapareció y en el otro se pegó al contador. En un caso el contador perdió el círculo.


Me resultó muy interesante como los dibujos se convirtieron en símbolos y una vez ahi se estabilizaron. Con más concurrentes, con dos seguidos que no conocieran la letra gama, seguro se hubiera distorsionado tambien.

Otro fenómeno fue que en un caso la hoja fue rotada y luego corregida.




Gracias a Christian Badenas por sus aportes a este texto.



Como siempre, es open source, pero si los lleva a la fama y el dinero, dejen caer sus migajas...



// Se podrá ver la versión profesional en http://tastycupcakes.org/ cuando junte ganas de adaptarlo a su formato

[offtopic] Exam Oriented Programming

Al tratar de comprender algoritmos de compresión para rendir exitosamente un examen, me he hallado ante una encrucijada:

Hacer todo en papel a manito: sin duda es lo mejor para un examen, pero cuesta mucho saber si lo que uno hizo funciona correctamente.

Implementar: bárbaro, asi sabemos si funciona o no, pero es inaplicable para un examen, ya que no se pueden ver los estados intermedios con representación humana. Uh, ¿que dije?

Supongamos AABBAA en LzHuff, que para el examen es "A(0)B(0)E(0)eof", que luego se traduce a asc("A") + 00b + asc("B") + 00b + asc("E") + 00b + 257d, todo esto pasado por dos árboles de huffman, claro. Termina en algo tipo 3FADD023.


La implementación en ningún momento me muestra algo asi. Además tengo que resolver un montón de problemas que no me sirven para el examen, ya que para este sólo necesito un "programa mental", mucho menos riguroso que el de la computadora.


La solución se halla en el medio y consiste en implementar un programa que haga lo que necesitamos para el examen, o sea que tome AABBAA y emita "A(0)B(0)E(0)eof" , en lugar de 3FADD023.  "A(0)B(0)E(0)eof" pasado por los árboles de Huffman es otro programa mental, que lo necesitamos de todos modos para el punto de compresión Huffman. Luego, la conversión a la representación hexadecimal es otro programa mental, que es trivial.

Ahora bien, para que esto no sea tan offtopic, podemos implementar ese programa con TDD. Comenzamos con:

void CompressorTest::testCompress_A(){
 string reference="A'0eof";
 MockedFileReader* in = new MockedFileReader("A");
 MockedFileWriter* out = new MockedFileWriter();
 Compressor *c = new Compressor(6,2,5);
 c->compress(in, out);
 CPPUNIT_ASSERT_EQUAL(reference, out->get());

 delete in;
 delete out;
 delete c;
} 

Luego con

void CompressorTest::testCompress_ABE(){
 string reference="A'0B'0E'0eof";
 ...
 CPPUNIT_ASSERT_EQUAL(reference, out->get());
 ...
} 

y asi... la buena práctica de TDD, elemento fundamental de la programación segura, es tambien útil para el estudio (malabares para no abrir otro blog con el tema de esta entrada)

Retrospectiva Agile Open Seguridad BA 2011

Comienzo con lo superficial que es la asistencia. Hemos logrado todo un record... de inasistencia. De un total de 33 inscriptos reales vinimos 11. Esto me hizo flaquear al principio, "los que estamos somos lo justo (o algo asi)" me resultaba poco reconfortante.

Pero no en vano es uno de los principios del formato open space. Cuando terminamos de proponer las sesiones ya tenia una fuerte desesperación compartida al menos por una persona mas (JP, el que mas hablaba) de "que sea unitrack, no me quiero perder ninguna" y eso que eran como doce.

Hicimos unitrack lo mas bien. El evento de conjunto tuvo como dos periodos. El primero fue mas ágil (sobre todo porque Charli tuvo inconvenientes para mostrar su ya habitual presentación de ciclo de desarrollar, vulnerar, testear, corregir) marcado por la fuerte presencia de Pablo Tortorela de Kleer y fuiba y un segundo mas seguro, al llegar Martin Tartarelli de Owasp que prácticamente hegemonizó dada su abismal diferencia de experiencia y conocimiento.

Una de las cosas que se destacaron en el cierre para los nuevos en este tipo de eventos es que pese a la falta de agenda el encuentro fue muy fructífero. De hecho, lo único que salió mal fue lo que estaba preparado, la presentación de Charli.

Algunos conceptos sobre los que se trató:

Defensa en profundidad
Análisis de riesgo
Control compensatorio
La aplicación es el nuevo perímetro
OWASP Top Ten
Open Space
Necesidad de difusión y concientización de seguridad
Cómo segurizar los proyectos ágiles

Algunas herramientas mencionadas:

ssl trip
metasploit
esapi
wireshark
apache benchmark
nmap
w3af
nessus
evil grade
warify
accunetics
honey pots
hdiv
tamper data
sentrigo

agiles-argentina@yahoogroups.com

 https://sites.google.com/site/comunidadagiles/agile-open-tour/agile-open-buenos-aires-2011---seguridad

Balance personal de Agile Open Security BA 2010

Recordemos que todo esto nació de  http://tech.groups.yahoo.com/group/agiles-argentina/message/535. Mi intención de tirar la piedra y correr no resultó. Pese a mis limitaciones tuve que cargar con mucho peso, sobre todo desde el momento en que conseguí un espacio en mi trabajo, Teracode.

El trabajo de organizar el evento me ha resultado agotador. Pese a la baja asistencia estoy conforme con los resultados obtenidos, aunque me quedó una cierta sensación de anticlimax.

Contaba con la asistencia de Martín Tartarelli (presidente de OWASP) o de Buanzo (reconocido miembro de OWASP), que como se deduce del "contaba", no asistieron. Supongo que aunque no haya hecho mucha diferencia, pudo haberle dado más peso institucional, como la presencia de emisarios rosarinos de Globant, que puede funcionar como semilla de un próximo evento más importante.



Algunas estadísticas:

Mails enviados: 125
Mails recibidos: 162

Si le damos unos dos minutos promedio por mail , tenemos 287 x 2 / 60 ~= 9.5 horas sólo de mails.

El preparar el taller, cuya exposición no estaba garantizada por las leyes del OpenSpace, me deber haber consumido no menos de 16 horas, sin incluir haberlo presentado un mes y medio antes en TC como Tech Talk. Y me quedó pendiendo usar shunit.


Tambien tuve la osadía de invitar durante la participación a dos eventos. No sé si rindió frutos.