Juego: Capture the Datacenter

En esta entrada explicaré los detalles técnicos de como armar una juego tipo "Capture the Datacenter" que es lo que hubo en la Ekoparty 2013 con el nombre de "La Caja" en el marco del Lockpicking Village de Infobyte. Esta entrada refleja lo que aprendí en compañia de todo el grupo y reflexiones posteriores mías. Hay una mezcla entre lo que se hizo, lo que no se hizo y lo que se podría hacer.

Como atacar cada sensor y subsistema es tarea para el hogar.


El concepto del juego es proteger físicamente un premio mediante cerraduras mecánicas y electrónicas y utilizar sensores de intrusión, haciendo una suerte de modelo de un datacenter.

El objetivo de la experiencia es un tanto turbio, tal como lo es el lockpicking y el pentesting, al respecto opino http://seguridad-agile.blogspot.com/2013/09/por-que-lockpicking.html


Si se quitan las cerraduras, los sistemas complejos de autenticación y la metáfora con la intrusión al datacenter, puede ser un interesante proyecto escolar, ya que para construirlo permite ejercitar el ingenio, obliga a aprender variadas técnicas y puede verse como un juego de ingenio, tanto para quien lo construye como para quien lo juega.

El contenedor

Se puede hacer de fibrofácil, que es una madera reconstituida relativamente resistente, fácil de trabajar pues carece de veta, con un peso aceptable. Es un tanto flexible, lo que puede afectar la alineación de algunos sensores.

Tip para el atacante jugador: no es conveniente apoyarse ni sacudir el contenedor.

La evolución de la forma fue: hagamos un desafío donde haya que obtener un premio abriendo cerraduras sin activar sensores tipo laser, movimiento, lo que sea, inspirado en un jueguito que hubo en segurinfo 2013, con unos espejos y un laser verde. Pero eso es difícil de calibrar, necesitamos mucho espacio bien protegido para que no se rompa. ¿Y si lo metemos en una caja y le ponemos algunas puertas? A ciegas primero, sin tapa despues, ponemos una malla de laser o infrarrojos, con acrílico cerrado, con un agujero, que se pueda sacar pero tenga sensores.

Hace falta proteger a los sensores, pongamos una tapa parcial de madera y particionemos con acrílico para que los sensores ópticos puedan actuar, luego vemos si hace falta perforar.


Fue muy interesante la evolución, como cada uno iba aportando y construiamos un modelo mental.

El problema de este tipo de desarrollo es que no es como software, donde refactorizás y listo. Cada tornillo que pongas en la caja queda marcado. Si cortás un vidrio o un espejo, queda cortado. No podés hacer backup, no hay versionamiento. No podés tener un entorno en la casa de cada uno.

Los sensores

Comencemos con el que descartamos, el laser infrarrojo. Como todos sabemos, el laser puede ser dañino para los ojos, uno infrarrojo que no se puede ver, queda entonces descartado, así como las trampas con ácido, electrocutantes o que digan malas palabras.

El laser rojo de 5mw ha sido probado reflejado con hasta siete espejos comunes y una distancia total de una veintena de metros, así que con unos pocos se puede hacer una malla bastante cerrada. El problema es que cada espejo aumenta la dispersión y que al atravesar el acrílico va teniendo reflejos fantasma que no aportan valor pues no ayudan a confundir al atacante. La próxima vez me parece que será mejor usar sólo dos espejos grandes y perforar el acrílico.

No se consiguen detectores de luz y un laser sobre una celda fotovoltaica no produce la suficiente corriente como para ser detectada. Sin embargo, los transistores infrarrojos detectan muy bien el laser rojo y los tubos fluorescentes y en realidad casi cualquier cosa. Ha resultado conveniente conectarlo a una entrada analógica para poder compensar en software los desajustes en la detección.

Con los transistores infrarrojos y leds infrarrojos se pueden hacer tambien detectores de interrupción de menor distancia, se podrían conectar a entradas analógicas o digitales según cada caso.

Tantos con unos comos con otros, se puede medir que el haz haya sido interrumpido. El inconveniente de este método es que se puede enfocar un laser externo sobre el sensor para anularlo. Para evitarlo, se puede modular una señal, pero sería mejor modularizarlo, poner la lógica en un microcontrolador y que provea una salida binaria al sistema detector.

El PIR (passive infrarred) es un sistema modular que detecta movimientos mediante cambios en la iluminación infrarroja existente. Es la típica cajita en la esquina del ambiente que se prende cuando te movés.

El detector por ultrasonido es otro sistema modular, arduino tiene kits. La salida es binaria tambien. Funciona emitiendo ultrasonido y evaluando el eco.

El detector de humo tambien es modular y se puede implementar con un par led/transistor infrarrojo. En una cámara oscura, se colocan sin que se "vean" pero cruzándose sus trayectorias. Cuando haya humo, este brillará iluminado por el led y afectará al transistor.

Motion es una aplicación que analiza un stream de video y según unas zonas configurables detecta movimiento. Esto se puede conectar a la aplicación controladora embebiendo las librerías o mediante pipes, sockets, según sea local o remota. Se puede considerar binaria.

Detector de contacto, es lo mismo que los botones de los ascensores, esos que no se presionan, sólo se tocan. Si no me equivoco, cuando los tocás hacés de antena para los 50/60 hertz de la red eléctrica que te rodea. Esto se puede implementar con un poco de electrónica o un microcontrolador.

Detector de tilt, es de los flippers, si sacudís mucho o cambiás el plano del contenedor, se activa. Se pueden usar  acelerómetros y modularizarlo.


¿Por qué un microcontrolador para cada sensor? Por el principio unix de que cada componente hace una sola tarea y la hace bien. Se puede conectar todo a un solo microcontrolador, pero ahí empezas con que tenés que implementar cosas complicadas, que no alcanza la velocidad para samplear, analizar y transmitir todo a tiempo. Es para usar unas pocos horas y no hay restricciones de espacio.

Y por último los simples interruptores. Son como botones de un timbre, si los apretás, suenan. Esos son "normalmente abiertos". Si son como los que prenden la luz al abrir la puerta de la heladera son "normalmente cerrados" y son los que más nos interesan. Se pueden conectar en serie muchos si son "cerrados" o en paralelo si son "abiertos" y considerarlos un solo sensor, así nos ahorramos patitas de entrada.

Un detalle a considerar con los interruptores es el "debouncing", el rebote. Cuando se abren o cierran la transición no es suave, se genera un ruido que puede ser necesario filtrar, ya sea por medios electrónicos o por software.

Si el detector de tilt se hace artesanalmente, se puede considerar un caso particular de interruptor.

La electrónica

Las fuentes de pc proveen varios voltajes útiles como 12, 5 y 3.3v. En esta experiencia en particular los laser eran de 3v y fueron alimentados meditante fuentecita regulada de 3v y paralelamente un puente de división de tensión de los 12v a 3v. Ambos funcionan.

Es conveniente usar cables y no alambres (varios hilos, un hilo) de distintos colores, conectores y borneras o pines, ya que el tener todo soldado en el aire con termocontraible y cinta aislante, aunque se ve lindo es muy difícil de mantener y diagnosticar.






Para conectar los módulos al microcontrolador principal una técnica muy práctica es usar optoacopladores, esto es un led del lado del módulo sensor y un transistor infrarrojo del lado detector. Esto sirve para que no tener que adaptar 12v a 5v ni que haya corriente circulando entre los distintos módulos.


             -----+              +--------------
                  |              |
            12v  led >-luz-> transistor        5v
                  |              |
             -----+              +--------------

Se arman con un sorbete, enfrentando los diodos y reforzando con cinta aislante o funda termocontraible.

Arquitectura

Una arquitectura posible es la siguiente:

 Cuando releía esto antes de publicar, encontré "hmi" en la arquitectura y me costó mucho recordar que quise decir: "human machine interface".

Para conectar el microcontrolador, un arduino, hubo que hacer un circuito impreso parecido al de la foto.

Abajo se puede apreciar al centro las resistencias para cada entrada analógica, que se conectan en los pines de la derecha. Usar cables de colores y anotar la polaridad en el impreso ayuda mucho.

Para las entradas digitales, pueden hacer falta resistencias pull-up o pull-down[1] para que no floten libres, que en esta encarnación no estan incluidas en el circuito y se deben poner cerca del diodo. Yo tenía entendido que los microcontroladores las incluyen y que se pueden configurar por software como up o down, pero quizás me estoy confundiendo con otro microcontrolador más poderoso.

Control físico de acceso

Cerraduras y candados en las puertas, cierre magnético controlado por autenticación biométrica. Las técnicas para burlar estos sistemas se explicaron en el Lockpicking Village y varios de los participantes pudieron de un modo u otro aplicarlas exitosamente.

Con respecto a la autenticación biométrica, sólo puedo decir http://seguridad-agile.blogspot.com/2013/11/por-que-no-biometria.html y su actualización http://seguridad-agile.blogspot.com/2015/09/por-que-no-biometria-redux.html

El software

El sistema controla los sensores, asignándole una penalidad a cada uno, lo cual incide en el defcon. Se puede calibrar la sensibilidad de cada sensor analógico e invertir la lógica, para lidiar con normal-abierto y normal-cerrado.

Esta es una captura de pantalla actual y luego un video de una versión primitiva

Se puede apreciar como el módulo de movimiento supera el umbral pero no se activa, pues está negado. La interfaz no es muy intuitiva, pero es lo que hay, busquen a un diseñador de interacción.

En el video se puede apreciar malamente como el cliente web actualiza con f5 la vista del defcon.

La evolución fue scratch[2] para arduino[3][4] como POC. Luego processing[5] [6] y terminó ejecutándose como applet dentro de eclipse. Desde processing para aca, todo fue versionado con git, salvo el software que va en el microcontrolador y se programa con arduino ide. Hubo que modificar el código que viene como ejemplo por la cantidad de entradas analógicas que vienen hardcodeadas, es que deben ser para otro modelo. Retrospectivamente, hubiese sido mejor no usar processing, pero tampoco fué tan grave.

El software está en https://github.com/cpantel/boxControl

Las reglas del juego

Es importante que hayan reglas claras para evitar malos entendidos y prolongar la vida útil del juego. Es importante definir el alcance, como que no vale cortar cables, desatornillar un panel, lo que sea.

La mejor regla es: "No rompas nada, dejá el juego en condiciones para que el próximo jugador pueda jugar".



[1] http://en.wikipedia.org/wiki/Pull-up_resistor
[2] http://scratch.mit.edu
[3] http://www.arduino.cc
[4] http://s4a.cat
[5] http://processing.org
[6] http://playground.arduino.cc/Interfacing/Processing‎

Por que no biometría

Es muy profesional mencionar los factores de autenticación y para no ser menos, los mencionaré:

• Algo que sé: una clave
• Algo que tengo: un token, tarjeta de coordenadas
• Algo que soy: biometría

Se está tendiendo a utilizar múltiples factores, de modo tal que si alguien se apodera de nuestra clave, no le alcance, pues le falta la tarjeta de coordenadas, por ejemplo.

if you want an english version, feel free to ask me for it

Algo que sé

Las claves son difíciles de recordar, moderadamente fáciles de robar. Si no tenés una cierta paranoia, fáciles de adivinar.

Las claves mal ingresadas suelen bloquearse tras algunos intentos fallidos, el proceso de desbloqueo o recuperación es incómodo. Alguien te puede bloquear la cuenta conociendo sólo tu identidad.

Las claves bien administradas son reemplazadas cada mes, lo que te obliga a tener patrones de claves que las debilitan.

Si respetás poner un símbolo y estás usando un teclado que no corresponde a tu configuración regional habitual, estás en problemas.

Atacantes obtienen bases de datos llenas de claves mal protegidas o directamente en texto plano.

En los ATMs se roban claves mediante cámaras ocultas y teclados falsos colocados sobre el teclado verdadero.

En Internet circulan claves en texto plano, tenés que prestar atención donde ponés tus claves.

No podés confiar en ningún servicio, así que tenés que usar claves distintas en distintos lugares.

Si tu máquina está comprometida, unos programitas llamados keyloggers capturan lo que escribís, por ejemplo al ingresar la clave de tu home banking.

Cuando escribís tus claves, pueden ser vistas por personas por sobre tu hombro.

Algo que tengo

Tarjeta de coordenadas, se gasta, se puede fotografiar o fotocopiar. La podrías ingresar completa en un sitio de phishing. No vos, claro, pero ocurre todos los dias.

Token, es caro. Es incómodo tener uno por cada identidad.

Todo lo que tengo se puede perder o ser robado.

Si lo pierdo o me lo roban, lo puedo dar de baja. Sólo en Misión Imposible me lo copian sin que me de cuenta.

La zona grís entre lo que sé y lo que tengo

Es evidente que no puedo saber cuarenta credenciales distintas, entonces las anoto... ¿las sé o las tengo?

Puedo usar un programa tipo KeePass y usar claves correctas en cada cuenta (las tengo), con el único riesgo de que sea comprometida la clave del almacén (la sé).

Algo que soy

La biometría es cool, apoyás el dedo, una cámara ve tu iris y entraste.

Si te asaltan ya no hace falta llevarte de paseo por los cajeros, con la tarjeta, la clave y tu dedo tibio recién cortado alcanza. ¿Otra vez Misión Imposible, en versión adultos? No, cada tanto le cortan un dedo a algún colectivero gratis  [1][2].

Si alguien compromete tu clave usás otra. Si alguien copia tu factor biométrico, fuiste.

¡Ah, pero eso es de re-espía! te convido un martini y me llevo tus huellas digitales.

No hace falta, con una foto alcanza. En vísperas del Lockpicking Village de la Ekoparty 2013, he comprobado que a partir de una impresión laser en poliester, se puede hacer una huella falsa que un lector más o menos normal acepta encantado. Yo no sólo disto de ser un experto en el tema, sino que fue mi primer, único y último intento, no basta con la suerte de principiante, evidentemente es fácil. Decenas de visitantes copiaron en pocos minutos sus propias huellas y pudieron burlar el mecanismo.

No he estudiado a fondo el asunto, pero según me han contado las otras personas del Lockpicking Village, lo que se almacena no es una imagen de la huella sino una representación. Supongo que a partir de esa representación se podría regenerar una huella que no engañaría a un perito pero sí a un lector de huellas.

Así como hay leaks de bases con claves, habrán leaks con bases de huellas.

Cambiando el cristal

Hasta aquí hemos visto el asunto desde el punto de vista del usuario, ¿cuál puede ser el del proveedor?

Obviamente, si da plata y todos se suben a la movida, el proveedor se ve obligado a adherirse. Pero, ¿qué va a pasar cuando haya un leak de la base de huellas y el usuario inicie acciones legales? Pues no es lo mismo perder las contraseñas [3][4] que algo que el usuario no puede reemplazar. El usuario podría argumentar que el proveedor le ha perdido la identidad. Se parece a haber perdido el anonimato [5].

Y luego, una vez que un proveedor ha perdido tus factores biométricos y te ha indemnizado, ¿qué pasa con el próximo que los pierda? ¿Te vuelve a indemnizar? Yo como proveedor quizás no querría aceptar la responsabilidad (o mejor dicho el costo) y me vería en necesidad de influir y manipular las leyes para que me sean favorables y esto podría llevar a "social unrest" si no fuera por que la humanidad parece embarcada en un tren de completa idiotez en lo que respecta a espejitos de colores digitales y las ventajas de la interconectividad.

Como proveedor no me preocuparía mucho.

Sí es sabido que es mala práctica repetir contraseñas en distintas cuentas, tambien lo es con los demás factores. La tarjeta de coordenadas o un token sólo sirven para una cuenta y esto es razonable, ya que los bancos no confian en los otros bancos para unificar la autenticación, son MIS clientes, ¿no? ¿Por qué el usuario final debe confiar SUS huellas, su iris o su adn?

Es que la autenticación biométrica se debe reservar para las cosas importantes, diría alguien con buen sentido. Pero como reza el dicho "con paciencia y con saliva, el elefante...", así como pasamos de tener cable sin cortes publicitarios a tenerlos, de un sellito del canal arriba a la derecha a un ocasional flash a un mensaje permanente, vamos a pasar de que las huellas se ponen en los documentos, a que en las credenciales de acceso a edificios inteligentes, a que desbloquean el smartphone, ese mismo que cambiás cada dos años o menos y lo vendés, regalás o perdés con tus huellas adentro [6].

Una opción que se me ocurre para poder convivir con la autenticación biométrica es restarle valor a los factores biométricos. Dictaminar que no basta como evidencia hallar una huella digital para relacionar a alguien con la escena del crimen, tambien debe estar en video. Estaba por decir "en el futuro" pero me parece que este ha ya llegado: el arte cinematográfico, modelado y animación 3D permite adulterar esa evidencia tambien. Pronto, la única manera de delinquir y poder ser acusado va a ser cometer el crimen en presencia de un escribano.



[1] http://www.ambito.com/noticia.asp?id=729777
[2] http://www.clarin.com/policiales/Asaltan-colectivero-plata-cortan-dedo_0_900510126.html
[3] http://seguridad-agile.blogspot.com.ar/2012/06/leak-linkedin.html
[4] http://seguridad-agile.blogspot.com/2013/11/leak-adobe.html
[5] http://seguridad-agile.blogspot.com.ar/2013/05/leak-mortal.html
[6] In two years your new smartphone could be little more than a paperweight http://smallbusiness.chron.com/life-expectancy-smartphone-62979.html

Leak Adobe - english

Leak Adobe

During last month, some whitehats seized a rotten server full with juicy data from adobe like user source code, account and credit card information.

For the technical aspects there are some links below  [1], [2], [3] being [4] the best one. There is some weak analysis about impact [5] [6]. The best analysis consist of getting a copy of users.tar.gz and run some greps and wc.

Adobe reacted fine, there is no leak on the password recovery process and there is even a security alert on the landing page, a hard hit to marketing.

The fact that the users reuse passwords among accounts it's not adobe fault. But encrypting instead of hashing is another thing. This failure opens the door to statistical analysis and the use of the hint field to recover a pretty nice top 100 [7] and somebody says the recovered password list climbs to six millons.

When it started, they say 3 millons, then 38 millons active accounts. The fact is that the list comprises 130 millons of mail/encrypted password/hint.

An attacker can gain some insight in the victim's way of choosing passwords in the best case and using the very same password if the victim reuses it in the worst case.

The best thing to do now as an user is to stop repeating passwords, change them if you are repeating. There is no gain in using a check system like [8], as we already know that all the database is stolen.

If someone decrypts the password by brute force or because they got it with the rest of the leak, it will be the worst attack, ever.



[0] spanish version http://seguridad-agile.blogspot.com.ar/2013/11/leak-adobe.html

[1] http://7habitsofhighlyeffectivehackers.blogspot.com.ar/2013/11/can-someone-be-targeted-using-adobe.html

[2] http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/

[3] http://www.hydraze.org/2013/10/some-information-on-adobe-135m-users-leak/

[4] http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/

[5] http://www.welivesecurity.com/2013/11/05/tom-hanks-and-donald-trump-among-850000-victims-as-limo-firm-hack-leaks-addresses-and-amex-numbers/


[6] http://blogs.wsj.com/cio/2013/10/08/adobe-source-code-leak-is-bad-news-for-u-s-government/



[7] http://stricture-group.com/files/adobe-top100.txt

[8] http://adobe.cynic.al/

Leak Adobe

En el último mes, gracias a que unos white hats se apoderaron de un servidor comprometido que se estaba usando para almacenar información ilegal, salió a la luz un espectacular y exitoso ataque contra adobe, que paulatinamente involucra un número cada vez mayor de credenciales, datos de tarjetas de crédito y código fuente.

Con respecto a los aspectos técnicos, hay varios artículos [1], [2], [3] y el mejor que he hallado es [4], nada agregaré. Hay varios artículos medio flojos acerca de las organizaciones afectadas [5] [6] ; sólo diré que hay 2300 direcciones relacionadas a gov.ar o gob.ar y 11000 que son @banco.* o @bank.*. El mejor análisis es obtener users.tar.gz y correr los greps y wc necesarios.

Como siempre, lo que más me interesa es el asunto de como afecta al usuario.

Adobe, por su lado, ha reaccionado desde el punto de vista técnico del modo correcto que hay que copiar. Cuando te logueas, independientemente de que tengas la clave correcta o no, te manda un password reset via mail. Además puso en la landing page el alerta, duro para los de marketing.

Volviendo al usuario, no es culpa de adobe que se usen claves repetidas, no hay nada que hacer. Pero el encriptar en lugar de hashear provoca que se pueda ver cuales claves son repetidas, lo cual permite hacer un análisis estadístico al que se suma el que muchas personas ponen una ayuda para recordar la clave demasiado explícita cuando no la misma clave.

Esta situación nos lleva a tener un top 100 [7] y según dicen unos seis millones de claves recuperadas.

Al comienzo se decía 3 millones, luego que eran 38 millones de cuentas activas. Pero eso carece de importancia. Lo fundamental es que está hay 130 millones, si MILLONES de entradas tipo "mail/clave encriptada/ayuda recuperación". Aunque no sean cuentas activas nos está proveyendo una clave candidata para probar frente a 130 millones de personas.

¿Cuál es mi ventaja como atacante? Si estoy atacando a una organización o una persona, tengo ya algunos mails y algunos con contraseñas. Los que se han descubierto hasta ahora son los más fáciles y seguramente los usuarios cometen el mismo error en los demás sitios. Ponele que alguno puso "jupiter" en adobe. En yahoo pruebo "jupiter", "zeus", "saturno" y así. En adobe puso "adobe2012", en yahoo pruebo... "yahoo2012", "yahoo2013" y así.

Para saber si tu cuenta de adobe fue comprometida o si no recordás si tenés cuenta, lo mejor es ir directamente al sign in de adobe. Como siempre, evitá usar los servicios como [8] que te ofrecen hacerlo por vos. Mucho más en este caso, donde se puede considerar comprometida la base completa.

Si alguien logra encontrar la clave que se ha usado para encriptar las claves, si es que ya no fue hallada como parte del leak o por fuerza bruta, este pasa a ser el ataque más exitoso que haya habido.

Lo peor de todo es que parece que la base era o un backup o un sistema de backup, ya que el sistema actual, según dicen, está correctamente implementado.

Lo más importante es que si reutilizás claves, abandones tan mala costumbre y cambies en breve las que puedas repetido en adobe.

[0] english version http://seguridad-agile.blogspot.com/2013/11/leak-adobe-english.html

[1] http://7habitsofhighlyeffectivehackers.blogspot.com.ar/2013/11/can-someone-be-targeted-using-adobe.html

[2] http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/

[3] http://www.hydraze.org/2013/10/some-information-on-adobe-135m-users-leak/

[4] http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/

[5] http://www.welivesecurity.com/2013/11/05/tom-hanks-and-donald-trump-among-850000-victims-as-limo-firm-hack-leaks-addresses-and-amex-numbers/


[6] http://blogs.wsj.com/cio/2013/10/08/adobe-source-code-leak-is-bad-news-for-u-s-government/



[7] http://stricture-group.com/files/adobe-top100.txt

[8] http://adobe.cynic.al/

Commodities vs diferenciables

Para poder fabricar La Caja del Lockpicking Village y ponerla en condiciones hubieron tres tipos de requisitos: commodities, diferenciables y algo en el medio. Esto lo descubrí en el proceso y como no soy tan vivo, intuí que deberían existir como tales en la teoría económica y así es [1]. Ya sabía de la existencia de commodities, pero es la primera vez que la sufro en carne propia.

Todo lo que voy a opinar ahora probablemente sea inexacto en términos económicos pero me resulta extremadamente útil a la hora de analizar lo que ocurrió y como mejorarlo. El objetivo de esta entrada es el análisis para comprender, aprender y mejorar, no es hacer una crítica sobre el proceso, aunque pueda parecerlo como un efecto colateral. Con respecto a ello, ver la entrada anterior[2]

Continuando, en nuestro caso, la diferencia entre ambas es que la commodity se resuelve con dinero y cuanto más dinero en menos tiempo. En cambio los diferenciables pueden requerir un tiempo que no se ve reducido drásticamente por el aumento de la inversión.

Nuestros commodities fueron

• computadoras
• cables
• switches
• conectores
• componentes electrónicos: laser, diodos y transistores infrarrojos
• fuentes pc
• ip camera
• router con wifi
• cerraduras
• candados

y lo son pues nos da lo mismo las marcas y modelos. Teniendo plata, voy a Galería Jardín primero y a la calle Paraná despues y tengo todo en dos horas.

Nuestros diferenciables fueron

• funcionamiento del sistema biométrico y su violación
• arquitectura, diseño y armado de la caja
• disposición de los sensores
• soft controlador 
• las reglas del juego

todo esto lleva tiempo, trabajo, iteraciones tras fallar.

Luego quedan estos elementos

• cierre magnético
• sensor biométrico
• arduinos
• diversos sensores
• maderas y acrílicos cortados

Los pongo en el medio pues no son tan fáciles de conseguir, ni son intercambiables: si se quemaba un arduino, teniamos que conseguir el mismo modelo o modicar el software y las conexiones. Aún así, se resuelven con dinero.

Nótese como dependiendo de quien lo vea, uno de estos elementos se puede convertir en commodity o diferenciables. Para un técnico electrónico experimentado, pasar de un arduino a un pic es un rato y además es más barato, para mi es cancelar el proyecto.

Una muy improbable serie de eventos desafortunados condujo a trabajo perdido intentando hacer funcionar discos rígidos que resultaron rotos o tras haber sido instalados fallaron y luego problemas de despliegue, al tener que resolver cosas a último momento lo que a su vez condujo a falta de testeo.

Otros commodities faltantes no tan commodities, muy relacionados con el diseño fueron infinidad de componentes de conexión. Había mucho soldado y empalmado en el aire, por no decir todo. De haber usado borneras y conectores, se hubiera reducido drásticamente el riesgo de cortocircuito, daño e incendio. Por un lado es lamentable que nada fallara de ese modo, ya que retrospectivamente uno dice "no hacía falta, no falló nada" y se acostumbra,  esa es la simiente del terrible próximo accidente.




El aprendizaje que saco de esta experiencia es que es importante al comienzo identificar los distintos tipos de elementos y tratarlos como tales, si hace falta una computadora, se delega. Al tener un equipo reducido con las tareas diferenciables antes mencionadas, hubiese sido mejor invertir en resolver todas la commodities lo más pronto posible para no perder el tiempo necesario para los diferenciables.


[1] http://en.wikipedia.org/wiki/Commodity
[2] http://seguridad-agile.blogspot.com/2013/09/ekoparty-2013-y-la-caja-de-lockpicking.html

Ekoparty 2013 y La Caja de Lockpicking Village

Hot fix

Debido a un error que he cometido, tengo la imperdible oportunidad de rehacer una entrada errónea del blog.

¿Por qué no borraste la entrada no bien notaste tu error? Por que me resisto a lo efímero de lo digital. Si lo borro, pasa al olvido mi error. Para mi es más traumático y perdurable que la entrada siga existiendo, para no volver a cometerlo otra vez. Además no quería provocar el efecto Streissand[1].

El error fue no haber consultado al grupo antes de publicar. Aparte, aunque el propósito de la entrada original era destacar la diferencia entre commodities y diferenciables, la falta de una cuidadosa redacción llevó a que el error tomara un caracter demasiado llamativo. Esto produjo el doble de ofensa.

Podría decir estaba cansado, resentimiento, que no me importaba o que quería apropiarme del mérito de la construcción de la caja, pero no, lamentablemente fue por mera torpeza y un exceso de entusiasmo, donde se me mezcló lo de commodities vs diferenciables con la crítica a la actividad, sumando la inercia de que casi siempre hago la crítica de todo lo que hago.

Reescribo entonces la parte de la opinión acerca de la Eko de conjunto y tacho el resto para que quede la evidencia. Commodities vs diferenciables[2] va a una entrada aparte como debió haber sido y en [3] los detalles de la caja. Recomiendo ahorrarme la vergüenza y saltar directamente a la entrada correcta.


[1] http://en.wikipedia.org/wiki/Streisand_effect
[2] http://seguridad-agile.blogspot.com/2013/10/commodities-vs-diferenciables.html
[3] http://seguridad-agile.blogspot.com/2013/11/juego-capture-datacenter.html

Ekoparty 2013

Del evento en si de conjunto mucho no puedo opinar, pues sólo pude asistir a la última charla y al cierre debido a que me quedé en Lockpicking Village casi todo el tiempo.

Antes, había pasado por el training de análisis forense de red, muy bueno, a cargo de Giovanni y Fernando de csiete. Según ya les comenté a ellos, me quedó un saborcito de falta de la práctica de la gestión que es mi parte floja y el motivo principal por el que había ido, como que hubo demasiado de la parte técnica. De todos modos me sirvió.

La última charla fué extremadamente interesante, acerca de las fallas de seguridad en los protocolos de dispositivos de control industrial que se suelen usar en la industria petrolífera.

En el 2011 cuando apareció en el cierre Nitromán al comienzo me pareció una completa taradez, pero despues me gustó, tanto que en el 2012 lo esperaba ansioso. En esta ocasión fué reemplazado por unos zanquistas saltones, simpáticos, pero extraño a Nitromán tirando el nitrógeno y quemando retinas. Igual sufrí por que he hecho zanquismo y usado los cositos para saltar y sé lo fácil que es caerse, me hubiera dañado mucho que lo hicieran.

Y eso es todo, aguardando ansioso la próxima, mejor con La Caja otra vez.




En esta ocasión no puedo contar mucho pues me ví muy absorbido por el Lockpicking Village y en particular La Caja. Muy lindos los muñequitos de luces brillantes que saltaban pero me gustaba más nitromán tirando el nitrógeno y quemando retinas. Antes, había pasado por el training de analisis forense de red, muy bueno a cargo de Giovanni y Fernando de csiete.

Para mi esta fué una experiencia muy particular por haber participado en la construcción y operación del Lockpicking Village.

El proceso de construcción...

... fué extremadamente caótico.

Para poder fabricarla y ponerla en condiciones hubieron tres tipos de requisitos: commodities, diferenciables y algo en el medio. Esto lo descubrí en el proceso y como no soy tan vivo, intuí que deberían existir como tales en la teoría económica y así es [1]. Ya sabía de la existencia de commodities, pero es la primera vez que la sufro en carne propia.

Todo lo que voy a opinar ahora probablemente sea inexacto en términos económicos pero me resultan extremadamente útiles a la hora de analizar lo que ocurrió y como mejorarlo. El objetivo de esta entrada es el análisis para comprender, aprender y mejorar, no es hacer una crítica sobre el proceso, aunque tenga un efecto colateral. Además, me considero desproporcionadamente responsable de los errores en relación a mi aporte dentro del proceso.

Continuando, en nuestro caso, la diferencia entre ambas es que la commodity se resuelve con dinero y cuanto más dinero en menos tiempo. En cambio los diferenciables pueden tener un tiempo que no se ve reducido drásticamente por el aumento de la inversión.

Nuestros commodities fueron

• computadoras
• cables
• switches
• conectores
• componentes electrónicos: laser, diodos y transistores infrarrojos
• fuentes pc
• ip camera
• router con wifi
• cerraduras
• candados

y lo son pues nos da lo mismo las marcas y modelos. Teniendo plata, voy a Galería Jardín primero y a la calle Paraná despues y tengo todo en dos horas.

Nuestros diferenciables fueron

• funcionamiento del sistema biométrico y su violación
• arquitectura, diseño y armado de la caja
• disposición de los sensores
• soft controlador 
• las reglas del juego

todo esto lleva tiempo, trabajo, iteraciones tras fallar.

Luego quedan estos elementos

• cierre magnético
• sensor biométrico
• arduinos
• sensor pir
• sensor ultrasonido
• maderas y acrílicos cortados

Los pongo en el medio pues no son tan fáciles de conseguir, ni son intercambiables: si se quemaba un arduino, teniamos que conseguir el mismo modelo o modicar el software y las conexiones. Aún así, se resuelven con dinero.

Nótese como dependiendo de quien lo vea, uno de estos elementos se puede convertir en commodity o diferenciables. Para un técnico electrónico experimentado, pasar de un arduino a un pic es un rato y además es más barato, para mi es cancelar el proyecto.


Me meto en este terreno tan ajeno a mis conocimientos pues más que descubrir los sufrí: hasta el segundo día aun no teniamos una computadora y eso produjo muchísimo trabajo perdido, al intentar varias veces hacer funcionar discos rígidos que resultaron rotos o tras haber sido instalados fallaron. Mientras, se uso mi computadora, cosa que no me gustó, luego explico bien.

El no tener la computadora desde algunas semanas antes produjo tambien problemas de despliegue, ya que por ejemplo, el acceso al dispositivo usb mediante el cual se comunica con el arduino, en linux mint no requiere configurar ningún permiso, pero sí en xubuntu, donde para no investigar tuvimos que ejecutar como root.


El haber perdido tiempo produjo tambien que La Caja no estuviera del todo terminada según nuestro criterio y que hubiera demora en el uso.

El despliegue tardío trajo entonces demoras por ajustes que se pudieron hacer en un ambiente previo, por lo cual hubo falta de testeo.

Otros commodities faltantes no tan commodities, muy relacionados con el diseño fueron infinidad de componentes de conexión. Había mucho soldado y empalmado en el aire, por no decir todo. De haber usado borneras y conectores, se hubiera reducido drásticamente el riesgo de cortocircuito, daño e incendio. Por un lado es lamentable que nada fallara de ese modo, ya que retrospectivamente uno dice "no hacía falta, no falló nada",  esa es la simiente del terrible próximo accidente.

Lockpicking es Seguridad Física y hemos violado todas las reglas de la Seguridad Industrial, salvo la de usar antiparras con el dremel y la amoladora.

La falta de calidad de la Caja se manifestó en la frecuente necesidad de ajustes, que bajaron el uptime. Por suerte para los breaks solía estar disponible y creo que casi nadie se quedó sin jugar.


De más está decir que todos estos problemas produjeron roces interpersonales e intrapersonales.

El mejor ejemplo de roce intrapersonal que tengo es que el jueves, cuando ya estaba funcionando todo y logré sacar mi computadora del juego, me dije, mañana no la traigo, total no hace falta. La verdad es que si no llevaba la computadora y algo fallaba nos quedábamos sin juego, así que la llevé. Por supuesto no hizo falta, así que la próxima vez no la llevo y esa vez si que va a hacer falta...

El problema de fondo es que yo no quería dejar mi computadora pues tengo un increible caos de que no he tenido tiempo de arreglar, información sensible y sin backup. Arreglar ese caos me quita tiempo... para La Caja.

Al tener un equipo reducido con las tareas diferenciables antes mencionadas, hubiese sido mejor invertir en resolver todas la commodities lo más pronto posible para no perder el tiempo necesario para los diferenciables. Debido a lo tarde que estuvo listo el sistema controlador, no hubo tiempo de hacer una buena transferencia  de conocimiento y hubo un lapso durante el cual me convertí en un single point of failure, es por eso que asistí a pocas conferencias.

Debo aclarar para que no haya confusión, que no hubieron problemas de dinero. Aunque no es mi intención repartir responsabilidades, en el caso particular de la computadora fue mayormente mía, ya que no sabía lo que sé ahora, no dije desde el primer momento "hace falta una computadora de tales características para antes de tal fecha". De haberlo dicho, hubiese estado. A medida que se acerca la fecha es cada vez más difícil conseguir cosas que antes es sencillo, ya que todo se acelera y lo sencillo cae fuera del backlog. Tuve una visión de hacker adolescente, te hago la máquina con partes recuperadas...

Me interesa una frase de Henry Ford que dice algo así como: Si para hacer algo necesitás una máquina y no la comprás, cuando termines vas a haber gastado la misma plata y no la vas a tener.


Lo bueno de esta experiencia, es que si la repetimos nos debería salir muy, muy bien. Por supuesto habrán nuevos errores, pero serán nuevos y bienvenidos.

Estamos viendo de reunirnos para analizar estas cosas y ver como el año que viene tenemos una caja mejor, con un uptime un poco más alto, no sé, veremos.

Como siempre, es muy interesante comparar las distintas apreciaciones: para mi la caja estaba llena de defectos, para el que la usaba era una maravilla a desentrañar, para el que la observaba era un disparador de ideas.

Y ahora, lo que realmente te interesa, La Caja... en una próxima e inminente entrega, mientras, invito a quienes tengan interés en lockpicking a unirse a https://groups.google.com/forum/#!forum/l0ckpickar


[1]http://en.wikipedia.org/wiki/Commodity

Por qué lockpicking

¿Qué tiene que ver el abrir una cerradura o candado con seguridad informática? ¿Por qué le estás prestando atención a esa actividad de ratero? Una persona que va a colaborar en el Lockpicking Village de la Ekoparty 2013 tuvo que solicitar que o no lo nombren o ponerle a la sección un nombre más "corporativo", tipo "Taller de Seguridad Física" para que en el trabajo no le cuestionen su participación.

English version here

Como que es algo entre trucho y adolescente, no es visto como algo serio. Me encontré una cadena para bici, "¿venía con la bici?" me preguntan.

Primera respuesta

Al abrir esa cerradura podemos sustraer un dispositivo, abrirlo para adulterarlo o acceder a claves escritas guardadas en un cajón, acceder a una terminal no protegida, a documentación sensible impresa, poner un keylogger usb, un splitter al video, un sniffer en la red, tomar una cinta de backup o, por que no, un disco en producción. Insuficiente, muy corporativa.

Segunda respuesta

La llave es un factor de autenticación[1][2], es algo que tengo. La contraseña, algo que sé. No me gusta mucho asi, quien tiene la contraseña escrita en un papel, no la sabe, la tiene, pero la literatura dice así.

El fabricante de la cerradura está en la misma posición que quien implementa un algoritmo de autenticación. El que instala la puerta, un sistema de autenticación.

El sacar una copia de una llave de modo subrepticio es equivalente al proceso de robar contraseñas ya sea por shoulder surfing, keylogger o phishing.

Las llaves se pueden copiar llevándolas al cerrajero o se puede obtener un molde o fotografía. Shoulder surfing es mirar por encima del hombro mientras alguien escribe la contraseña, keylogger es un programa que captura lo que uno escribe y lo envía al atacante, phishing es engañar a alguien para que ingrese sus contraseñas en un lugar falso bajo nuestro control.

Mover el pestillo sin girar el mecanismo de cerradura es equivalente a aprovechar una falla de diseño en un sistema criptográfico o en una aplicación web, como CSRF o session fixation.

Un ejemplo de lo primero es el can shim[3] de Deviant Ollam que es usar una lata para abrir un candado, equivalente a usar una tarjeta en una puerta. La explicación de CSRF no es tan sencilla, pero básicamente es hacer que un sitio bajo nuestro control haga una solicitud a otro usando la sesión de la víctima. La de session fixation tampoco es sencilla, pero permite obtener una sesión autenticada sin conocer ni obtener las claves.


El impressioning, que consiste en usar una llave virgen para detectar las marcas de los pines e ir limando hasta obtener una llave que abre, se parece a un timing attack donde se deduce la clave a partir del tiempo que le lleva al sistema de autenticación responder según los valores que se introduzcan.

No veo paralelo para lifting, que es ir abriendo la cerradura de a poco, poniendo los elementos en su lugar. En cierto modo se parece al timing attack, salvo que no obtenemos la llave, sólo la apertura.

El racking es una versión medio bruta de lifting, como probar muchas combinaciones que es como un ataque de fuerza bruta. En el caso de un candado de combinación es probar todos los números posibles. Pero racking más se parece a un ataque de diccionario, que en el caso del candado sería usar los números más frecuentes.

Si un password está hasheado y el atacante obtiene ese hash y logra una clave que aunque distinta a la original tiene ese mismo hash (colisión se llama), es como si tuviera una llave maestra.

Si una persona tiene las mismas claves en distintas cuentas, si un sitio es comprometido, el atacante puede atacar todas las cuentas. Es como tener una sola llave para todas las puertas.

El bumping es básicamente pegarle a la cerradura con una llave especial y a lo que más se parece es a un buffer overflow para cambiar el flujo de ejecución

Comparación de vulnerabilidades

	saltea mecanismos de autenticación	obtiene copia de la contraseña o llave
keylogger	no	si
shoulder surfing	no	si
phishing	no	si
csrf	si	no
session fixation	si	no
dictionary	no	si
brute force	no	si
collision	en cierto modo	en cierto modo
buffer overflow	si	no
timing attack	no	si
repetition	no	implica que se obtuvo la primera
key copy	no	si
can shim	si	no
lifting	no	no (*)
impressioning	no	si
racking	no	no
master key	en cierto modo	en cierto modo
social engineering	si	probablemente
bumping	no	no

Responsabilidades y prevenciones

	responsable	prevención
keylogger	usuario	no instalar malware
shoulder surfing	usuario	ser mas vivo
phishing	usuario	ser mas vivo
csrf	proveedor	token secreto
session fixation	proveedor	descartar sesión
dictionary	usuario	que no esté en un diccionario
brute force	destino	fortalecer(**)
collision	proveedor	mejorar algoritmo (***)
buffer overflow	proveedor	no confiar en 0 como fin de string
timing attack	proveedor	comparaciones en tiempo fijo
repetition	usuario	usar distintas claves o llaves
key copy	usuario	no dar llave
can shim	proveedor	bloquear pestillo
lifting	proveedor	mejorar diseño (****)
impressioning	proveedor	pines redondeados
racking	proveedor	mejorar diseño (****)
master key	compartida	asumir el riesgo
social engineering	usuario	ser mas vivo
bumping	proveedor	resortes distinta fuerza

(*) Supongo que alguien con la suficiente experiencia podría reconstruir la llave a partir de haber aplicado éxitosamente el método. Hace muchos años, fui a un cerrajero a hacer una copia del departamento de mi abuela. Era una llave común de paletas sin identificación. El cerrajero la miró y me dijo "ah, la de Doña XXXX".
(**) Fortalecer es hacer más larga y compleja, exigiendo letras mayúsculas, minúsculas, números y símbolos.
(***) Si el atacante no conoce el algoritmo, no puede hallar colisiones. La teoría dice que el algoritmo no es secreto, pero la defensa en profundidad dice que si.

(****) Incluye usar pines especiales, resortes de distinta fuerza y una huella más retorcida.


Ahora no tanto, pero hace un tiempo se podía tocar mucho timbres en un edificio y alguien te abría. Esa es una de las tantas maneras de aplicar ingeniería social. Se parece a encontrarse una sesión sin bloquear.

Insuficiente, muy académica.

Tercera respuesta

Hay otra respuesta, que es el estado mental, la actitud. El espíritu del lockpicking es el mismo que el del hacking. Paralelamente, el objetivo del ladrón que vulnera una cerradura es el mismo que el de que distribuye malware.

La sensación de abrir una cerradura sin la llave es parecida a la de hackear un sistema, en situación de laboratorio o en el marco de un ethical hacking, claro.


Hace muchos años había leido un artículo que lamentablemente no puedo recuperar. No sé si era correcto, que valor tenía. Pero decía que en algún período de la antigüedad los cerrojos no eran efectivos por si mismo sino por el respeto que imponía quien los había puesto. Abrir el cerrojo de un cofre real no era simplemente violar la cerradura, que parece que era muy fácil, sino actuar contra la autoridad del rey.

Tras haber asistido a los Lockpicking Villages de las Ekoparty 2011, 2012 y preparándome para 2013 y haber probado lo aprendido en varias ocasiones, he llegado a la conclusión de que el artículo es correcto.

Un poco más de lockpicking en http://seguridad-agile.blogspot.com/2013/04/disposable-pick-tools-for-office.html

Para ver los resultados de La Caja, http://seguridad-agile.blogspot.com/2013/09/ekoparty-2013-y-la-caja-de-lockpicking.html

Si te interesa el lockpicking, https://groups.google.com/forum/#!forum/l0ckpickar

Referencias

[1] http://en.wikipedia.org/wiki/Multi-factor_authentication
[2] http://seguridad-agile.blogspot.com/2013/11/por-que-no-biometria.html
[3] http://deviating.net/lockpicking/media/can_shim.avi

Dos dimensiones extra en la evaluación de vulnerabilidades

Hay algo que a veces recuerdo mencionar en los talleres de tdsd y que es la gran diferencia que existe entre sqli y xss, que recién ultimamente he generalizado y paso a detallar.

(En 2019 actualicé y extendí un poco este tema)


Para comparar y priorizar vulnerabilidades, existen los principios de seguridad de la información: Confidentiality, Integrity, Availability[1], que a la hora del sopesar riegos suele aparecer como algo parecido a Riesgo = Probabilidad * (C+I+A) y fórmulas más complejas como  Common Vulnerability Scoring System[2] Version 2 Calculator[3], que incluye CIA y agrega otros factores.

Estas fórmulas se aplican a cada vulnerabilidad hallada para decidir que hacer. Sin embargo, veo que hay dos elementos ausentes. Para descubrirlos, veamos la diferencia radical que existe entre sqli y xss.

SQLI

Con sqli tenemos la completa responsabilidad e impacto. Esto es, no hay factores desconocidos o fuera de nuestro control. No tenemos excusa técnica para poder asumir el riesgo o mitigarlo parcialmente, (recordemos que ante un riesgo podemos: evitarlo, asumirlo, mitigarlo o transferirlo[4]), tenemos que arreglarlo.


Si hay algo estructural en el dbms, debemos hacer el upgrade o buscar la manera de evitar sql, pues no nos pueden cambiar el saldo de una cuenta o el equivalente en nuestro negocio.

XSS

Con xss la cosa es distinta, la verdad es que es una vulnerabilidad compartida, hay navegadores que interpretan de modo distinto lo que se le envía, nosotros no podemos contemplar la inmensa variedad de navegadores y sus versiones, ni siquiera podemos decir "nuestro sitio es inmune a xss para todos los navegadores en sus últimas versiones". Y si lo dijéramos sería en vano, ya que la mayor parte de la gente no tiene las últimas versiones.

En este caso hacemos lo mejor posible, sobre todo para evitar xss almacenado, que permite un defacement.

Las dimensiones faltantes

 

Esta diferencia hace surgir a la primera dimensión: "quién es el responsable". Nosotros no confeccionamos los standards, no desarrollamos los navegadores. Es algo que escapa a nuestro control. Sí recibimos los mensajes y podemos quitarle todo lo que dañe a nuestro sistema.

La segunda dimensión es "a quién afecta". Un cambio en el comportamiento del sistema me afecta a mi y quizás al cliente, el robo de credenciales sin duda al cliente.
En el momento en que el cliente enfadado se vaya a otro lado y arrastre a otros la fórmula me empieza a afectar tambien a mi.

Cuando a mi me roban las contraseñas del cliente, por más que neutralice el ataque inmediatamente, el cliente se ve afectado si usa las mismas en otros sitios o al verlas se puede deducir el patrón de generación. Asi que es responsabilidad del cliente protegerse de mi falta de responsabilidad.


Tambien puede ser que cada cliente haga su evaluación intuitiva de riesgo(*) y ya esté tan acostumbrada a perder sin nada a cambio que no tiene mucha resistencia a exponer su privacidad a cambio de unos amigos virtuales.
Veamos ahora las dos dimensiones trabajando sobre una misma vulnerabilidad:

Ejemplo fijación de sesión

Este consiste en que el atacante accede al sitio de interés y recibe unas cookies de sesión. De alguna manera se las ingenia para que el atacado acceda al sitio de interés con esas mismas cookies y en el momento en que se autentica, el atacante se autentica tambien pues tiene las mismas cookies de sesión.

Es un ataque difícil, pues no es tan sencillo hacer que el navegador tome cookies así nomás. Depende mucho de una mala implementación en el navegador y así se parece a xss en la dimensión de responsabilidad.

Sin embargo, el impacto es tan fuerte como fácil de arreglar que ni vale la pena evaluar el riesgo, sólo hay que cambiar el cookie de sesión en el momento en que cambia el nivel de autenticación. Dije "cambia el nivel" y no "cuando se autentica", pues esto vale cuando un "usuario" se convierte en "administrador" tambien.

Este caso además es más sencillo de explotar si nuestro sitio tiene xss, que es una vulnerabilidad mucho peor.

Ejemplo de fortaleza de claves.

Con respecto a las claves doy por supuesto que si hay autenticación, hay https con las suites actuales, que las claves se almacenan con salt & pepper(**), que no hay sqli/ldapi y que ya no queda nada por hacer del lado del servidor. Doy por cumplida mi parte en "quién es responsable". Que le roben o adivinen las credenciales al cliente no es nuestra responsabilidad, pues ahí viene al rescate nuestro contrato que dice que toda operación avalada por sus credenciales son su responsabilidad, asi que a nosotros no nos afecta.

Veamos el detalle y como podemos afectar:

• Claves repetidas, se puede evitar.
• Complejidad y longitud, se puede exigir.
• No se puede evitar la reutilización en distintos sitios
• No se puede evitar que las ingrese en un sitio malicioso mediante phishing
• No se puede evitar que use contraseñas relacionadas con datos personales que no tenemos.

Reflexión personal acerca de la responsabilidad

Me voy a ir un poco por las ramas, pero lo que quiero transmitir es el sentido de la responsabilidad y para ello voy a usar un ejemplo extremo de la realidad.

Veamos estas noticias 

Choque en cadena en la Panamericana: un muerto

Hubo 11 vehículos involucrados. La causa habría sido la niebla.[5]

Cuestionan la falta de prevención para evitar accidentes en la niebla

Expertos dicen que hay que poner detectores y una central de información[6]

Impresionante choque múltiple en la Ruta 2: dos muertos y varios heridos

Fue a la altura del kilómetro 129, en la mano a Mar del Plata. Participaron al menos veinte autos. La visibilidad estaba reducida por un incendio de pastos en la banquina...[7]

Y algunos textos seleccionados:

"Los voceros precisaron en un primer informe que el accidente se pudo haber producido a causa de la baja visibilidad debida a la intensa niebla que afectaba la zona."

"Según informó Ernesto Arriaga, vocero de Vialidad Nacional, el choque se habría debido a[l humo proveniente de] una quema de pastizales."

La privación sensorial, generalización de la niebla, existe desde antes que los autos, los caminos, la civilización, las personas, pero no antes que la vida. Si no vés, temé, andá más lento. Contra eso no hay solución, sólo nos queda la Selección Natural como protección a largo plazo y lidiar con los daños colaterales. Es un conocimiento básico, elemental. Quizás no te pueda enseñar las leyes de la fricción; se debe acusar a la concesionaria de la ruta por no señalizar un derrame de combustible que hace que la ruta sea resbaladiza pero si chocás en la niebla es tu responsabilidad.

Aun así no hay mucha solución individual, ya que si lo hacés bien te exponés a que te choque un candidato a los Premios Darwin[8]. ¿Qué hacés? te vas a los carriles lentos y vas aminorando con el ojo puesto en el espejito hasta que ves que tenés alguien atrás tuyo para protegerte del de más atrás que no frena, no sé, no soy muy automovilista, sólo estoy abusando de mi sentido común.

Si viéramos la niebla como una vulnerabilidad y a la luz de las dos dimensiones diría que "a quien afecta" es al automovilista, "quién es responsable" seguro que ni yo ni el cliente. Esto no nos sirve, pues la niebla es una amenaza, la vulnerabilidad es la privación sensorial en velocidad. De esto es responsable el automovilista. Como en el caso de las credenciales, lo ayudaré, voy a poner esas marcas en el piso que indican el nivel de niebla, intentaré capacitarlo, lo que nos lleva al siguiente punto.

Capacitación

Scheneir dice que "...training users in security is generally a waste of time, and that the money can be spent better elsewhere." En el mismo artículo [9] tambien dice otras cosas, vale la pena leerlo todo.

Supongamos que está en lo correcto. Lo que expone es desde el punto de vista de las organizaciones, ya sean empresas o gobiernos. Pero desde el punto de vista tuyo, vos, no el "usuario" que engrosa estadísticas sino vos que si te roban la identidad sufrís, no sirve mucho.

Es evidente que el consejo se aprovecha a medias, no se le da capacitación a los clientes y el dinero se usa en cualquier otra cosa, pero no para la seguridad, la prueba de esto es que muchos de los ataques más sonados son evidente resultado de aprovechar fallas bastante sencillas que o no fueron vistas por no destinar recursos(***) o siendo conocidas quedaron muy abajo en el backlog ya que no agregan valor.

¿Qué hacés entonces? Como usuario final no vale la pena que las organizaciones me capaciten (a menos que me lo puedan cobrar) y que los productos sean más o menos seguros no afectan al ROI.

Defensa Personal Informática

Ves de alcanzar un mínimo conocimiento aunque sea intuitivo, aprendés algunas recetas y las aplicás. Es lo que hacés para vivir en tu hogar, aunque no sepas las leyes de la electricidad, evitás tocar la heladera estando sin calzado y con el piso húmedo. No necesitás saber que existe sqli ni bases de datos, sólo que no podés contar con que una contraseña ante un sitio no se haya ido de paseo por otros lados, entonces, usas una contraseña distinta en cada sitio. No necesitás saber de CSRF ni html, sólo que cuando hacés homebanking no deberías navegar absolutamente nada más.

A diferencia de los accidentes, que son una probabilidad, los ataques son resultado de una evaluación de costo beneficio por parte del atacante. Si hay alguna deidad afectando tu destino, no tiene un cupo de accidentados que cumplir. Existe un nicho de asaltados pues responde a una necesidad económica, no existe un nicho económico de los que se patinan y se caen, sí existe un nicho que se beneficia de ello. Supongo que en análisis de riesgo debe haber una distinción para lo que estoy diciendo.

Glosario

defacement: cuando se cambia un sitio por otro. Se puede reemplazando el sitio original o mediante xss "dibujarle" encima.

sqli: ataque que consiste en modificar las consultas sql, las de la base de datos, de modo tal que se puedan traer resultados distintos a los previstos e incluso modificar los datos del mismo modo.

xss: ataque que consiste en poner código donde sólo se supone que hay datos y que se activa al llegarle al navegador, pudiendo tomar el control de la navegación o capturar credenciales

xss almacenado: cuando el código para xss queda almacenado en la base de datos del  sitio.

xss reflejado: cuando el código para xss está en un link que la víctima recibe por fuera del sitio atacado.

Notas

(*) al decir intuitiva no la considero menos efectiva 
(**) salt es un valor al azar que se almacena en el mismo registro del usuario y se utiliza para formar el hash que se almacena en lugar de la clave en texto plano, pepper es otro valor global a todo el sistema y que no se almacena ni en la base ni en el código. Juntos, son bastante efectivos para neutralizar rainbow tables.
(***) Con destinar recursos me refiero a capacitación, incorporación de desarrollo seguro y auditorías. 

Referencias

[1] https://www.owasp.org/index.php/Secure_Coding_Principles#Core_pillars_of_information_security
[2] http://www.first.org/cvss
[3] http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2

[4] https://www.owasp.org/index.php/Application_Threat_Modeling#Mitigation_Strategies

[5] http://www.clarin.com/gran_buenos_aires/Choque-cadena-Panamericana-muerto_0_904709772.html

[6] http://www.clarin.com/sociedad/Cuestionan-prevencion-evitar-accidentes-niebla_0_523747674.html
[7] http://www.clarin.com/sociedad/Impresionante-choque-multiple-Ruta_0_974902829.html
[8] http://www.darwinawards.com/

[9] http://www.schneier.com/blog/archives/2013/03/security_awaren_1.html

Confianzas

Esto ocurre en una cc: agile. Va a sonar como si estuviera retando, pero es sólo parte del relato, ok? El diálogo es imaginario, la acción desencadenante no.

if you need an english version, ask me for it

>Los datos son:
>Usuario: xxxxxxxxxxxxx
>Pass: xxxxxxxxx

Hola YY

[hablando con quien publicó las contraseñas]

ch: Pienso que debiste haber preguntado quienes necesitaban o querian las credenciales y enviárselas sólo a quienes manifestaran interés.

yy: ¡Eh!, ¿para quien querría alguien hackear agiles xxxxx?

ch: Aunque no hubiera nada de valor, para divertirse, para vengarse, para exhibirse.

yy: ¡Eh, estamos en un grupo de confianza!

ch: Supongamos que hoy si, mañana quien sabe.

[hablando con los receptores]

ch: ¿Quienes al recibir esta credenciales fruncieron el ceño?

ch: ¿Quienes evaluaron si las necesitaban y las movieron a otro lugar?

ch: ¿Quienes borraron el mail?

ch: La cuenta de mail de alguno de los receptores puede ser comprometida en algún momento, si el mail está, están las contraseñas. Además, según ocurrió, luego hubieron reenvíos del mail donde quedaron las contraseñas y aunque aparentemente no se propagó a otras personas, la información ha quedado en múltiples mails que quizás no se borren o se usen para responder o reenviar

[hablando con todos]

todos: Ok, entendimos, ¿qué hacemos?

ch: cambiar la contraseña, poniendo de paso algo un poco más fuerte, igual la vamos a anotar en algún lado, es de uso infrecuente. Luego, la distribuimos entre las personas necesarias de un modo más pensado. Y aprendemos para la próxima vez.

Fin del diálogo

El problema fundamental es de la falta de reflejos. Dicen que el buen programador al cruzar la calle mira a ambos lados aún en las calles de una sola mano.


Pero lo que a mi me interesa en esta ocasión es La Confianza. Pienso que hay dos tipos de confianza: la moral y la técnica.

La moral la podemos despachar pronto, pues se trata de la eterna lucha del Bien contra el Mal, si sos mi amigo o enemigo, si sos honesto o chorro, blanco y negro, el ying y el yang y además se puede comprar.

Me resulta más útil escribir sobre la confianza técnica, que consiste en la capacidad de alguien de no perjudicarte.

¿No te da un poco de miedo cuando cruzás la calle frente a un auto que aunque el semáforo esté en rojo el conductor tiene puesta primera y el embrague apretado sea lo que evita que te arrolle?

En el caso verídico que inicia esta entrada, vemos como hay confianza moral y como podemos debemos desconfiar técnicamente de las mismas personas. Alice le transmite a Bob un secreto pues confía en que él no la traicionará. Pero Bob, sin ninguna mala intención, no almacena de modo correcto las contraseñas y luego las divulga accidentalmente o las pierde al ser su cuenta comprometida.

Lo que es una pena, es que ha pasado más de un mes y la clave no fué cambiada, de hecho, quizás llegaste hasta acá por el twitt enviado desde la  cuenta en cuestión. Espero que nadie se ofenda, ya que ha sido sin malicia. Si fuera bien "full disclosure", ¡estaría twitteando las credenciales!


¡Bah! ¿pero qué valor tiene la cuenta esa de twitter? Aunque sea sólo un juego, es exactamente el mismo escenario del de una cuenta de valor. Perdiste en el juego, vas a perder en el "realidad".

Agile Open Educación 2013 y los dos pies

Dejando de lado una leve desprolijidad con la comida, que los concurrentes no creo que hayan notado, todo salió de maravillas. Hubo un buen porcentaje de asistencia, hubieron muchas y variadas sesiones. Incluso yo, que soy bastante quejica, no me puedo quejar.

Design Thinking

Convocada por Ezequiel Kahan. trató de un método de análisis.
Me resultó interesante la etapa de ponerse en el lugar del otro, que es algo que siempre he considerado útil y beneficioso.

No regalamos caballos de Troya

Me quedó desligado la segunda del título "No regalamos caballos de Troya", en el sentido que según relaté, muchos han rechazado mis ofrecimientos de capacitación quizás por una cierta desconfianza, en el sentido de "y despues me vas a pedir que...", cosa que no había. El dato útil que me llevé es que los centro culturales suelen estar ávidos de actividades gratuitas y no son tan burocráticos como las escuelas.

Experiencias de enseñanza de seguridad

Me olvidé de mencionar que había llevado juegos, lo que quizás influyó en que no hubiera suficiente asistencia como para jugarlos. Para mi pesar, las personas asistentes no tenían experiencia, venían a ver.

En ambas sesiones quedé en una situación un tanto incómoda, pues aunque aclaré en ambos casos "compartir experiencias", como que quedé de expositor.

Enseñando a programar

Convocadas por Lucas Videla y Mariano Tugnarelli, fue lo que más me gustó del evento. Me llevo a Alice, que es como scratch pero mucho más divertido  y tambien el método de hacer los algoritmos a mano con cosas. Al escribir esto recuerdo que hace mucho tiempo intenté hacerlo en Algoritmos I, pero no le aposté lo suficiente, además en mi posición de colaborador ad honorem, no podía afectar el centro de gravedad de la cátedra.

Los dos pies

Incluso yo, que soy bastante quejica, no me puedo quejar. Aún así, me voy a sacar las ganas de quejarme.

En el Open Space hay un regla, la de "los dos pies", que se suele explicar como  "si no estás aprendiendo o contribuyendo en una sesión, se requiere que te levantes y que te dirijas hacia otra sesión en desarrollo, donde sientas que eres más útil y te sientas más inspirado"

A mi no me gusta esa definición, no es un mero derecho del asistente, pues no lo necesita, ni en un agile open ni en ninguna otra ocasión.

Para mi esta regla es más una protección para el convocante o expositor si lo hubiera y para el resto de los participantes de la sesión. Estamos acostumbrados a la idea de que si alguien se levanta y se vá es una agresión.

La reformularía así: "No te quedés por compromiso en un sesión en que no estás aportando ni recibiendo, tampoco pretendas que nadie lo haga. Intentá adaptar  la sesión y no te ofendas si alguien lo hace"


Lo que me molesta es que más que un derecho se ha convertido en una obligación moral, que no sólo está presente en un Open Space si no en muchas otras actividades. Si no te gusta, andate. Es la completa enajenación de tu actividad. Sos un recurso y como tal, no sos dueño de tu producto. Ahora bien, no te comportes como un recurso pues sos una persona, manifestalo ejerciendo tu derecho a irte. No transformes la realidad que no te gusta, cambiala por otra, en otro lado, sin indemnización, sin problemas, en el cielo.

Mutation Testing Framework

Presento aquí el resultado de mi trabajo colectivo de mutación de código para testing. Digo "colectivo" por las horas que invertí en análisis y diseño viajando en colectivo[1]. Seguramente estoy reinventando la rueda[2], pero no me importa, el camino avasalla en importancia al destino.

If you need an english version, ask me and I will add it to the top of my backlog

He utilizado bastante TDD pues de no ser así hubiese incurrido en pecado mortal. Hay que predicar con el ejemplo. Es más, el proceso fue reflexivo, se aplicó contra su mismo codigo fuente. Con respecto a este tema, me interesa aclarar que para mi TDD es tan sólo una técnica más, un recurso en nuestra valijita de herramientas. No significa que uno se sienta con la mente en blanco y tira un test y el código y así avanza. Me parece correcto hacerlo así en un taller de TDD, pero si nos detenemos ahí, es como quedarse con la idea de que la danza clásica son las posiciones de los pies y agarrarse de una barra frente a un espejo, que tocar el piano son unas escalas, boxear es saltar la soga y perseguir gallinas o programar es implementar sort() y search().

Mi idea original fue utilizar php que tiene un tokenizador[3] y es lo que más conozco, para mi desgracia. Cuando en los primeros viajes comencé a percibir que podía haber mucha recursividad pensé en erlang, el cual necesito practicar para recupera mi autoestima. Inmediatamente rechacé la idea, KISS[4]. Dos viajes después, tras haber visto que python tambien tiene un sencillo tokenizador[5] (y quizas ruby[6] y cobol[7]) y percibiendo el potencial de utilizar multicores en múltiples máquinas, había reincorporado erlang y en lugar de un mutador de código para php tenía en mente un framework para usar con cualquier lenguaje que alguien se tomara la molestia en preparar. Bueno, ese era el plan.

Testing por mutación

El testing por mutación de código se basa en la idea de que si los test están bien hechos, deberían detectar cualquier cambio en el código fuente. Entonces, hay que modificar arbitrariamente el código respetando las reglas del lenguaje y ejecutar los tests, alguno tiene que fallar. Si no es así, falta cobertura o faltan casos.

Las mutaciones sobre las que decidí trabajar son las más sencillas: cambiar operadores aritméticos y de comparación, no mucho más que eso. Para hacer cambios más complejos hay dos opciones: usar un AST[8] y ver como manipularlo o generar más mutaciones que serán eliminadas por el compilador (o interprete en la primera etapa).

El proceso consiste en tomar un archivo fuente, obtener los tokens, generar un archivo fuente variando un token, luego otro y así, siempre ejecutando los tests y esperando que no falle, en cuyo caso, se corta y avisa al humano para que mejore los tests.

En [9] cuento superficialmente mi experiencia académica de uso con Jumble, un mutador de código para java y otras técnicas de automatización de test. Este proyecto es resultado de haber tomado el curso "Generación Automática de Tests Unitarios" (ECI 2012 N2) [10] a cargo de Nazareno Aguirre [11], Universidad Nacional de Río Cuarto, Argentina

Alcance

Mis metas fueron haciéndose cada vez más ambiciosas:

1. mutador de codigo para php
2. framework para varios lenguajes
3. usando erlang
4. con procesamiento paralelo y distribuido
5. comprender el trasfondo teórico
6. para poder usar otros lenguajes que no tienen el tokenizador tan accesible y hacer mutaciones más complejas

He decido que hay tres etapas y sólo transitar la primera, quizás la segunda. Eventualmente, si surge la necesidad, la tercera.

Loops

Un problemas interesante que intuí es que si tocás la condición de un loop, podés entrar en infinito. Esto produce que haya que darle un tiempo máximo de ejecución a cada test. Lo que debe hacer al comienzo el framework es una ejecución normal de referencia en cada nodo para tomar el tiempo y usarlo como base para el timeout de las ejecuciones sobre el código mutado. Si hay timeout, considero que el test falló, o sea que esta ok.

Código original:

for ($i = 0; $i < 5; $i++)

Mutaciones:

for ($i = 0; $i <= 5; $i++) -> debería fallar el test

for ($i = 0; $i <= 5; $i--) -> loop infinito

Aunque luego exploro la posibilidad de controlar de modo selectivo algunas mutaciones, lo que implementé fue ejecutar un test de referencia para tomar el tiempo y luego usar timeout para cortar en caso de anomalía.

 

Combinatoria

Otro problema es la combinatoria. Si para cada token que es mutable se hace toda la combinatoria con los otros, el número puede llegar a ser muy, muy alto. No sé por que esa fué mi primera idea, pero pronto caí en cuenta de mi error y sólo se hacen las combinatorias para cada token independiente de los otros.

Dado

if a + b == c

tenemos

if a (+,-,*,/,%,^) b (<,>,<=,>=,!=,==) c

Si combinara todo tendría  6 x 6 = 36 ejecuciones, pero sólo hago 6 + 6 = 12. Con dos tokens mutables parece poca diferencia, pero si fueran cien tokens tendriamos 6¹⁰⁰ = 6¹⁰⁰ en lugar de 6 x 100 = 600. Unos pocos segundos contra algunos millones de años.

Falsos positivos

El siguiente código tiene una mutación que es inocua ya que produce el mismo comportamiento y sin embargo parece un error:

<?php  $i = 0; while ($i != 5) {    print "$i\n";    $i++; }

<?php  $i = 0; while ($i < 5) {    print "$i\n";    $i++; }

Queda un criterio humano final para decidir.

Concurrencia

Otro problema más, relacionado a la ejecución simultánea de los tests es la concurrencia sobre las distintas versiones del código. Una manera es replicar el ambiente para cada instancia. Dije "instancia", no "nodo", o sea que en una misma máquina con N cores hay N instancias. La otra es... tuve un esbozo pero lo olvidé, ya volverá cuando haga falta.

Arquitectura

La comunicación entre el componente del lenguaje y el core es mediante un mensaje json[12]. El componente del lenguaje debe identificar cada token con su valor y su clase. Había pensado que los tokens no mutables se simplifiquen en uno solo, de modo tal que:

if a + b == c {
  printf("hola");
}

se tokeniza:

if
a
+
b
==
c
{
printf
(
"hola"
)
;
}

y se simplica:


"if a" 
+ operadorAritmético
b
+ operadorComparación
c { printf("hola"); }

pero esto es optimización prematura, y le da a cada componente de lenguaje la responsabilidad duplicada de simplificar, así que decidí que el core se encargue de simplificar, aun así es responsabilidad del componente del lenguaje identificar la clase:

if       -> inmutable
a        -> inmutable
+        -> operadorAritmético
b        -> inmutable
==       -> operadorComparación
c        -> inmutable
{        -> inmutable
printf   -> inmutable
(        -> inmutable
"hola"   -> inmutable
)        -> inmutable
;        -> inmutable
}        -> inmutable

y definirla:

operadorAritmético extiende simétrica
   mutaciones: +,-,/,%,*

habiendo dos tipos de clases, las simétricas y las asimétricas, esto es porque hay elementos completamente intercambiables y otros que no:

operadorControl extiende asimétrica
   elemento: break
     mutaciones: continue, exit, blanco
   elemento: exit
     mutaciones: blanco
   elemento: continue
     mutaciones: break, exit, blanco

Por ejemplo, clone se puede reemplazar por =, pero no al revés.

El mensaje en json se parece a esto:

{
"header": [
     {"version":"1.0"},
     {"language":"php"}
   ],
"classes": [
     { "name":"assignment",
       "type":"symmetric",
       "pool":[ "+=","-=","*=","/=",".=","="]
     },
     { "name":"clone",
       "type":"asymmetric",
       "genes": [ {"gene":"clone",
                  {"pool":["="]
                ]
     },
     ...
  ],
"tokens: [ {
     "class":"inmutable",
     "value": "<?php"
   },
   {

     "class":"inmutable",
     "value": "$a"
   },
   {

     "class":"assignment",
     "value": "="
   },
   .... 
 ]
}

Aunque firmemente empeñado en no hacer el componente de python y mantener el alcance del proyecto reducido, recordé que hay un framework de unit testing de python llamado doctests [13] que tiene el código embebido en el mismo archivo fuente, como comentarios. Era lo que se usaba en w3af[14], pero me ha dicho Andrés, el papaito de w3af, que no escala.

Si el mutador mutara el código de testeo estariamos en problemas, ¿no? Hay que inventar algún mecanismo para lidiar con esto. Me imaginé, no probé, que el tokenizador lo consideraría comentario y no habría inconvenientes. Pero un segundo antes, ya había hallado la solución, que por casualidad sirve para lidiar con los falsos positivos y los loops.

La idea es usar una nueva clase "signal", que indique al core si debe mutar o no. Por ejemplo

<?php

se convertiría en:

{
 "class":"signal",
 "value":"<?php",
 "action":"start"
}

o en dos tokens, el normal de "<?php" y el signal, al que le podríamos quitar "value". Me gusta más la segunda opción, así tenemos dos canales, el de datos y el de control.

El componente python debería insertar como primer elemento:

{
 "class":"signal",
 "action":"start"
}

Luego, en el código, habría que insertar comentarios con una etiqueta arbitraria, a gusto de quién implemente. En php será #code_mutator_start|stop.

while... /*#code_mutator_stop*/ ) {
  ...
#code_mutator_start
  ...
}

Esto es feo, pero simple.

Uno puede sentir la tentación de usar tambien "action":"pause", como para que el core tenga un comportamiento distinto según sea "pause" (sigue aplicando la lógica) o "stop" (concatena todo el resto), pero sería optimización prematura.

La precaución que hay que tener es como procesar en el componente el manejo de estas etiquetas, ya que el código del componente debe ser mutable.

Por ejemplo,

if ($value == "#code_mutator_stop" )

provocaría que el core deje de mutar no siendo esa nuestra intención.

Se soluciona asi:

if ($value == "#code_mutator"."_stop" )

Esta técnica para falsos positivos abre la puerta a solucionar los loops infinitos, usando una nueva action:
{
 "class":"signal",
 "action":"restrict",
 "genes":["-=","/="]
}

Esto le avisa al core que no puede usar esos genes en los próximos pools, hasta que venga una nueva restricción, que puede ser vacía. Por ahora, dejemos esta puerta cerrada.

Otra puerta que tampoco quiero abrir es una clase para poder mutar valores enteros.

Por fortuna, justo me puse a leer Domain Specific Languajes[15] de Fowler, lo cual me ayudó a reflexionar mucho acerca de este mensaje que circula desde los componentes hasta el core. No califica de DSL, pero sí aplican muchos conceptos.

En algún momento, había resuelto simplificar la estructura de los token:

"tokens: [ {
     "signal": "start"
   },
   {
     "inmutable": "<?php"
   },
   {
     "inmutable": "$a"
   },
   ....   ]


pero me encontré con un inconveniente. ¿Qué pasa si quiero pasar metadata, como por ejemplo la linea y columna del token en el archivo fuente? Esto es algo indispensable para python:


"tokens: [ {
     "signal": "start"
   },
   {     "inmutable": "<?php"
   },
   {
     "metadata": [{ "row":"1"},{"col":"0"}]
   },
   {
     "inmutable": "$a"
   },
   {
     "metadata": [{ "row":"1"},{"col":"6"}]
   },
   ....   ]
No me gusta, me complica el procesamiento, asi que mejor conservo la estructura original que permite procesar de modo mucho más sencillo elementos adicionales y le agrego un campo "info".

"tokens: [ {
      "class":"signal",
      "action":"start"
   }
   {
     "class":"inmutable",
     "value": "<?php",
     "info": [{ "row":"1"},{"col":"6"}]
   },
   {
     "class":"inmutable",
     "value": "$a",
     "info": [{ "row":"1"},{"col":"6"}] 
   },
   {
     "class":"assignment",
     "value": "=",
     "info": [{ "row":"1"},{"col":"6"}] 
   },
   .... 
 ]

Este ejemplo es una ilusión en php, que sólo provee información de lineas y lo hace mal. Python da más información.

Seguridad

Más por disciplina que por una necesidad real:

Los puntos de ataque son mensajes json mal formados y el resultado de la ejecución.

Resultado de la ejecución: el proceso se agota cuando se hacen todas las mutaciones o no falla alguna, asi que no hay denegación de servicio por ahí.

json: no hay loops, no hay denegación de servicio por ahi. Quizás si hay muchos tokens o tienen valores muy largos haya que tomar alguna precaución.

Lo que si podría ocurrir es que el componente inyecte código malicioso para que sea ejecutado luego por xUnit. Pero esto no afecta al core, no me importa.
Como Tom Lehrer le hizo decir a von Braun: "'Once the rockets are up, who cares where they come down? That's not my department', says Wernher von Braun."[16]

Ahora en serio, el componente podría por si mismo ejecutar el código malicioso. Sólo tendría valor en caso de que este sistema progresara a la arquitectura multinodo, para propagarse a otros nodos.

Alcance de la primera etapa

Me contento con que funcione una sola instancia que entienda php y python. Esto es para respetar el espíritu agile: sólo implemento lo que produce valor tangible. Yo no necesito ahora los componentes para otros lenguajes ni necesito analizar tanto código que justifique múltiples instancias. Si bien me vendría bien ver como funcionan otros tokenizadores, estaría invirtiendo trabajo en algo que quizás nunca desarrolle.


Esta visión aparentemente de corto alcance no se contradice con mirar al horizonte y hacer una apuesta, es por eso que el framework de ejecución tiene su core en erlang:

• Es más sencillo pasar luego a una versión concurrente y distribuida
• Me sirve para practicar. Aunque no al proyecto, me da valor a mi.

No es que me haya lanzado a codear con la mente en blanco, tuve casi dos semanas de análisis "colectivo" hasta que pude ponerme frente a una máquina

Como mencioné antes, los componentes han sido mutados, no así el core en erlang y bash, al que sólo apliqué eunit[17] y sshunit2[18].



El código completo está disponible en https://github.com/cpantel/codeMutator, hay un Makefile que corre diversos tests, pero antes hay que instalar unas dependencias, lee REAME.md

Me faltan varias refactorizaciones como poner la definición de las clases (las de los tokens) en modo composición para poder modificarlas sin tener que rehacer los tests. Tambien que los .sh sean más generales.


[1] http://es.wikipedia.org/wiki/Colectivos_de_Buenos_Aires
[2] http://stackoverflow.com/questions/246495/what-mutation-testing-frameworks-exist
[3] http://php.net/manual/en/book.tokenizer.php
[4] http://en.wikipedia.org/wiki/KISS_principle 
[5] http://docs.python.org/2/library/tokenize.html
[6] http://pic.dhe.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic=%2Fcom.ibm.debugtool.doc_11.1%2Fvrmu1mst109.htm
[7] http://www.ruby-doc.org/stdlib-1.9.3/libdoc/ripper/rdoc/Ripper.html
[8] http://en.wikipedia.org/wiki/Abstract_syntax_tree
[9] http://seguridad-agile.blogspot.com.ar/2012/09/automatizacion-de-test-eci-2012.html
[10] http://www.dc.uba.ar/events/eci/2012/cursos/aguirre
[11]  http://dc.exa.unrc.edu.ar/staff/naguirre/Pagina_personal_de_Nazareno_Aguirre/Principal.html

[12] http://www.json.org/
[13] http://docs.python.org/library/doctest.html
[14] http://w3af.org
[15] http://martinfowler.com/books/dsl.html
[16] http://en.wikipedia.org/wiki/Tom_Lehrer 
[17] http://www.erlang.org/doc/apps/eunit/chapter.html
[18] http://code.google.com/p/shunit2/