2013/11/25

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‎



2013/11/06

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/

2013/11/05

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/