Remediando la seguridad nacional (¿qué se supone que debo hacer?)

Kill the messenger

He recibido comentarios varios por parte de colegas quienes también trabajan en seguridad informática, mencionando que el documento publicado aqui: http://www.fsockopen.com/seguridad-nacional/remediando-la-seguridad-nacional-01 posee diversas fallas ortográficas y clasificaciones inadecuadas de las vulnerabilidades, e incluso menciones sobre algunas “anomalías”, por así decirle, las cuales no son fallas de seguridad o no conllevan un riesgo.

Por lo cual dedicí explicar un poco las condiciones bajo las cuales fue creado el documento.

(1) 24 horas.

Todas las anomalías, fallas de seguridad, y las mismas pruebas de concepto fueron realizadas en un día. Mismo día en el cual escribí y publiqué el informe. Quiero ser claro con esto, todo lo que es posible ver en el contenido de http://www.fsockopen.com/seguridad-nacional/remediando-la-seguridad-nacional-01 fue descubierto, creado y documentado en un lapso de 24 horas. Ya que había una reunión programada para el día Lunes 27/09/2016 en la cual, quería presentar tanta información como me fuera posible conseguir.

(2) Adhonorum, y ni siquiera.

2. No estoy bajo ningúna circunstancia publicando esto por intereses personales, sino, todo lo contrario. Hasta el día de la fecha no he hecho más que dedicar tiempo y dinero para la documentación y presentación de estas fallas de seguridad y comprender cuales son las circunstancias que permiten y dan origen a que esto pueda suceder. No he recibido ninguna clase de remuneración o compensación económica hasta el día de la fecha por lo que he hecho, y no solo eso, sino que muchos encontraron mal que haya publicado el documento.

(3) “No veo ninguna falla de seguridad”.

3. He recibido comentarios particularmente sobre la falla presentada en la siguiente prueba de concepto: http://fsockopen.com/sec_pocs/fallas_nacionales/dni_secuencia_cors_mas_valocidad_xss/

Dado que muchos no entienden exactamente que es lo que pasa cuando se aprieta el boton comenzar, paso a explicarlo:

  1. La web https://tramitesweb.mininterior.gob.ar si bien posee un certificado y HTTPS. Dado el uso no adecuado de headers HTTP conocidos como Access-Control-Allow-Origin, permite ser incluida dentro de un <iframe>.
  2.  Haciendo uso de ese mecanismo, y AngularJS, se genera un micro-navegador dentro de un iframe, usando un modelo angular. Esto es parte de la tecnología que he decidido utilizar a fin de probar la falla de seguridad.
  3. Si intentaramos entrar de manera directa por medio de un iframe hacia https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=3 el servidor devolvería una redirección dada la falta de cookies, por eso, la navegación Angular comienza recorriendo 2 links iniciales a fin de la creación de cookies.
  4.  En esta instancia cualquier persona que acceda a este mecanismo creado en AngularJS, ya estaría haciendo pedidos sin saberlo a la página oficial del ministerio del Interior, Obras Públicas y Vivienda de la Presidencia de la Nación. Permitiendole a un atacante realizar un ataque sin utilizar su propia dirección, sino, lanzando el ataque desde multiples computadora que accedan al link con el mecanismo de Angular.
  5. Se procede a enviar formularios, lo cual no sería posible sin la existencia de una segunda falla de seguridad conocida como XSRF o CSRF. El controlador PHP no verifica que los formularios provengan desde la capa visual de la aplicación, aceptando de esa forma que el formulario sea enviado desde un dominio externo. Al llegar a este punto estamos haciendo uso de una falla que muchos considerarían “Frameable Response” combinada con “XSRF/CSRF”. Los formularios se envían con mi información personal, para evitar que más personas me miren mal.
  6. Se hace uso de una tercera falla de seguridad conocida como XSS persistente. El controlador ubicado en https://tramitesweb.mininterior.gob.ar:443/TramiteWebDNI/generar.php almacena la información de los primeros pasos del formulario, posiblemente en una base de datos ya que lo único que puedo observa en cookies es mi session ID (tramitesweb.mininterior.gob.ar: PHPSESSID=f1kql54dk2k6mkhj08dbbd15a3) y preasumo, dadas las condiciones generales de la web, que no hace uso de HTML5 Local Storage / Web Storage.
  7. El XSS que bien, dicho sea de paso, podría ser una inyección SQL es almacenado en la db. No sería posible realizar esto sin otra falla de seguridad, que es la carencia de validación de información recibida por el usuario en el controlador. En otras palabras: https://tramitesweb.mininterior.gob.ar:443/TramiteWebDNI/generar.php debería de verificar la validez del input enviado por el usuario, y no un JS, como es el caso, ya que es posible, (como podemos observar), pasar por alto las validaciones realizadas por el JS, comunicandonos directamente con el controlador.
  8. En conclusión, la prueba de concepto, prueba la existencia de las siguientes fallas:
    1. Frameable response (Configuración inadecuada de Access-Control-Allow-Origin)
    2. XSRF (es posible enviar información de menera directa al controlador, el formulario es prescindible y al igual que sus mecanismos de validación JS).
    3. XSS (el servidor almacena mi inyección de HTML y JS, realizadas por medio de XSRF y un iframe, en una db)
    4. Las fallas de seguridad de seguridad se ven en la pantalla del usuario.
  9. Para los que deseen más información técnica sobre lo que hace el codigo, pueden verlo, ya que es JS:

Como verán, el mecanismo principal, realiza 4 inclusiones de mecanismos auxiliares, los cuales son usados para hacer el XSRF:

En orden cronológico, el primero (corresponde a “Paso1”, como podemos ver en el código):

El segundo (corresponde a “Paso2”):

El Tercero (corresponde a “Paso3”):

El final (que corresponde a “Paso4”, como podemos ver en el código):

(4) Addendum de (3 “No veo ninguna falla de seguridad”).

Para los que no llegan a ver las posibilidades, el controlador parece, o bien, digamos, podría ser vulnerable no solo a un XSS sino a una inyección SQL. Si ese fuera el caso; el mecanismo creado por medio de Angular, dada la presencia de las demás fallas de seguridad, harían posible que una persona publique en facebook, o cualquier red social una vulnerabilidad así, y decenas de personas disparen una inyección SQL hacia los servidores sin siquiera saberlo, gracias a la “weaponización” de las fallas en los headers de acceso en combinación con el XSRF. De no ser así, no sería posible.

(5) Algunas de las anomalías publicadas no son fallas de seguridad.

Si, es verdad, algunas de las anomalías publicadas, como el hecho de que la web www.buenosaires.gob.ar diga “sarasa”, no son fallas de seguridad, pero son prueba clara del descuido que hay al crearlas. Del mismo modo que podemos encontrar recursos olvidados diciendo “sarasa”, podemos ver recursos de instalación de un Drupal, y varias cosas más que revelan información y deberían de ser eliminadas del servidor. En especial, dado que no sirven para nada y exponen al servidor a más riesgos de manera innecesaria. Considero que hay que sacar lo que no se usa o lo que no sirve, más que nada cuando puede generar un problema.

(6) Es irresponsable hacer la información pública.

Es aún más irresponsable vivir en un país lleno de profesionales en seguridad informática, creadores de Core Security Technologies en 1996 (https://en.wikipedia.org/wiki/Core_Security_Technologies) y ser incapaces de resolver fallas de seguridad que ponen en riesgo la información de millones de ciudadanos.

Se que hay miles de personas acá que son capaces de reconocer las mismas fallas de seguridad que he localizado y mencionado. Pero, ¿Por qué nadie informa, por qué nadie considera que sea un riesgo? ¿Por qué consideramos que es “normal” que las condiciones sean esas? ¿Por qué aceptamos que las cosas sean así y no hacemos nada para remediarlo? ¿Por qué no hacemos algo para remediarlo? ¿Por qué en vez de ayudarme, critican lo que estoy haciendo?

Muchos de Uds saben que la seguridad online de la Nación es débil, desde hace muchos años. Creo que es responsabilidad de quienes sabemos algo sobre seguridad informática hacer algo para remediar las condiciones.

(7) Pero de nuevo, ¿por qué hacerlo público?

La razón por la cual decidí hacer el documento público es porque previo a hacer el documento público, me comuniqué con:

  • Andrés Horacio Ibarra (https://www.linkedin.com/in/andrés-horacio-ibarra-44421417) (por Linkedin) (me refirió a…
  • José Hirschon (con quien no logré comunicarme…)
  • Daniel Abadie (https://www.linkedin.com/in/danielabadie), (por email)
  • Eduardo Jorge Martino (https://www.linkedin.com/in/eduardo-jorge-martino-b199ba28), (varias conversaciones Telefónicas)
  • Diego Gonzalez (Director de Ciberseguridad, Subsecretaría de Tecnologías y Ciberseguridad, Ministerio de Modernización) (reunión del Lunes 26)
  • Oscar Morotti (reunión del Lunes 26).

En la reunión con Diego y Oscar, mencionaron que el organismo de ciberseguridad de la nación, localiza he informa diversas fallas de seguridad en organismos y servicios web de la república a diario y envían comunicados hacia los organismos responsables casi a diario.

Sin embargo; el problema, de acuerdo a El Director de Ciberseguridad, Subsecretaría de Tecnologías y Ciberseguridad, Ministerio de Modernización, es que las organizaciones responsables (como podrían ser los responsables de un servicio web que corresponde a una provincia o bien, un organismo del gobierno, solo por dar una idea) muchas veces, en su mayoría, no reconocen las fallas de seguridad y/o no le dan la relevancia necesaria para remediar las mismas.

Lo cual sugiere un problema serio en los mecanismos de comunicación y corrección de fallas de seguridad de La República. Es inconcebible que el país, disponga de un organismo dedicado pura y exclusivamente a la detección y notificación de fallas de seguridad a nivel nacional, y que los diversos organismos, los cuales son informados, no hagan nada para resolverlo. Asumiendo claro que la información dada por Diego y Oscar sea válida, lo cual, no dudo en lo más mínimo.

Las aplicaciones y los servicios web que corresponden a la república, son creados, -asumo, y generalizo- con dinero de que proviene del Pueblo, de cada uno de los miembros de la comunidad que llamamos país. Del mismo modo los sueldos y el dinero asignado a las diversas organizaciones públicas que realizan su labor a diario.

Si uno de los mecanismos falla, como podríamos mencionar el caso de la policía y las leyes, o bien, lo que podemos ver acá; lo que se genera es un problema:

Disponemos de personas creando aplicaciones web, que exponen la seguridad de los miembros de la comunidad, disponemos de un equipo especializado en informar las fallas de seguridad, el cual no siempre es escuchado, y disponemos de organismos capaces de que crear y publicar aplicaciones y servicios web con vulnerabilidades, sin revisiones previas, que pueden exponer a la sociedad a riesgos y no escuchan las recomendaciones del área de modernización.

(8) Conclusión:

Como sociedad, debemos crear un mecanismo válido de comunicación y prevención de fallas de seguridad, con la dinámica necesaria para cambiar la condición. Las organizaciones y los responsables de los diversos servicios web del país deben ser informados y de alguna manera, creo, que debería ser obligación, la corrección de cualquier falla de seguridad que haga posible, hacer cosas como las que ya he publicado.

 

Comments

comments

chris

Programo, escribo, leo, cuido animales, colecciono flora, fauna, perfumes y oleos, reviso e informo fallas de seguridad para organizaciones y empresas.