Ekoparty 2013 y La Caja de Lockpicking Village

Hot fix

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

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

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

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

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


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

Ekoparty 2013

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

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

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

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

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




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

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

El proceso de construcción...

... fué extremadamente caótico.

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

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

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

Nuestros commodities fueron

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

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

Nuestros diferenciables fueron

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

todo esto lleva tiempo, trabajo, iteraciones tras fallar.

Luego quedan estos elementos

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

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

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


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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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


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

Por qué lockpicking

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

English version here

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

Primera respuesta

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

Segunda respuesta

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

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

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

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

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

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


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

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

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

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

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

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

Comparación de vulnerabilidades

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

Responsabilidades y prevenciones

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

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

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


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

Insuficiente, muy académica.

Tercera respuesta

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

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


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

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

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

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

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

Referencias

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

Dos dimensiones extra en la evaluación de vulnerabilidades

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

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


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

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

SQLI

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


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

XSS

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

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

Las dimensiones faltantes

 

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

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

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


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

Ejemplo fijación de sesión

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

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

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

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

Ejemplo de fortaleza de claves.

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

Veamos el detalle y como podemos afectar:

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

Reflexión personal acerca de la responsabilidad

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

Veamos estas noticias 

Choque en cadena en la Panamericana: un muerto

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

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

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

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

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

Y algunos textos seleccionados:

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

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

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

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

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

Capacitación

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

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

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

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

Defensa Personal Informática

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

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

Glosario

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

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

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

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

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

Notas

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

Referencias

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

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

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

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

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

Confianzas

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

if you need an english version, ask me for it

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

Hola YY

[hablando con quien publicó las contraseñas]

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

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

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

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

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

[hablando con los receptores]

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

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

ch: ¿Quienes borraron el mail?

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

[hablando con todos]

todos: Ok, entendimos, ¿qué hacemos?

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

Fin del diálogo

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


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

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

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

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

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

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


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