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