lunes, 25 de noviembre de 2013

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‎



1 comentario:

  1. Buen artículo, cuando se contrata este tipo de servicios también puede venir a mano conocer algunas formas de Cuidados de un servidor .

    ResponderEliminar