Etiquetacross-site scripting

MyStore vulnerable a Cross-Site Scripting: Miles de sitios afectados

MyStore es una plataforma de comercio electrónico (eCommerce) escrita en PHP y utilizada por miles de sitios web. La plataforma tiene una vulnerabilidad Cross-Site Scripting en el archivo usado para desplegar errores al usuario, en el módulo de administración y es accesible por cualquier usuario sin previa autentificación, por lo que es posible explotar la vulnerabilidad y preparar un ataque hacia los clientes de los sitios web que implementan el sistema.

Según Google, son un poco más de mil sitios los que utilizan esta plataforma y que serían vulnerables a este tipo de ataques.

Al tratarse de un eCommerce, esta vulnerabilidad es aún más peligrosa ya que el atacante podría explotarla para obtener información de los usuarios como números de tarjetas de crédito, correos, usuarios y contraseñas, todo esto mediante phishing, usando el dominio del sitio en el que el usuario confía. Tambien se pueden elaborar ataques mas sofisticados para robar las sesiones a los usuarios que previamente hayan iniciado sesión.

Seguir leyendo

Banco Central de Chile vulnerable a XSS

El sitio web del Banco Central de Chile es vulnerable a ataques Cross-Site Scripting y, posiblemente, un SQL Injection. Son muchos los sitios de bancos que son vulnerables a este tipo de ataques, pero muy pocos quienes solucionan los errores luego de reportarlos, es por eso que se toma la decisión de hacer un disclosure sobre las vulnerabilidades para denunciar este tipo de hechos.

El sitio web del Banco Central pareciera no tener ningun tipo de validación de los parametros de entrada que se pasan mediante formularios o mediante URL, exponiendo a los usuarios  y al servidor a distintos tipos de ataques.
El XSS que encontré, está en el archvo rim/default.asp en el subdominio si2.bcentral.cl.

Como prueba de concepto, incrustaré un ‘iframe’ con el sitio web de Google dentro del sitio del Banco Central

Perfectamente, el atacante podría incrustar un sitio malicioso con la intención de robar la identidad del banco y aprovecharse de la confianza que el usuario tiene sobre el sitio web, incluso usando el sitio “seguro“.

Tambien el atacante podria, mediante esta vulnerabilidad, modificar el formulario de inicio de sesión que aparece en la imagen, para robar los datos de los usuarios y enviar la información a terceros.

Seguir leyendo

Está preparado el gobierno chileno para recibir un ataque de robo de información ?

Ultimamente se han puesto de moda los ataques de “Anonymous”, ataques como tirar un sitio abajo o saturación de servidores, algo bastante simple que no requiere mucho conocimiento y es por esto que mucha gente se ha sumado. Algunos medios los han llamado ‘hackers‘ otros ‘simples aficionados que se descargan un programa, introducen una URL, se coordinan y presionan enter‘. Por suerte del gobierno no se comparan con los ataques originales de Anonymous o LulzSec. Cuando digo “originales” me refiero a esos ataques que han salido a la luz donde divulgan información sobre las cuentas de usuario e información sensible y privada de las empresas, no a unos wannabe.

Según mi opinión, un ataque de denegación de servicio a sitios del gobierno no tiene ningun sentido y no hacen daño ni provocan preocupación, creo que los ataques deberian realizarse hacia “servicios” y no a “sitios”, donde se vean afectados los servicios que los ciudadanos usan y que el gobierno se sienta incapaz de brindarselos. Esto sucede porque no se hace un estudio sobre la víctima, para darle donde más le duele, se puede llamar “ataque organizado” porque se acuerdan una hora y todos presionan el botón ese dia a esa hora, pero no hay una real coordinación donde se investigue un objetivo donde realmente llame la atención, y mientras siga siendo así, seguiran siendo ataques simbólicos.

El gobierno chileno tiene muchas brechas de seguridad informática y de la información, es por esto que me hago la pregunta, ¿Está preparado el gobierno de Chile para recibir un ataque de robo de información?, la respuesta clara es: NO. No está preparado el gobierno, ni las personas, ni los encargados, no existen políticas (y si existen no se cumplen), encargan su seguridad a un simple firewall que solo les sirve para que sus empleados no puedan ingresar a ver youtube. Obviamente no puedo decir que “todas las entidades del gobierno tienen fallos de seguridad”, pero me refiero al gobierno en general.

Desde hace un tiempo que he estado investigando las distintas vulnerabilidades web en sitios del gobierno, intentando reportar la mayoría. En algunos casos no responden, en otros casos no hay forma de contactarlos pero en el mejor de los casos, recibo respuestas y unas satisfactorias gracias.

Seguir leyendo

Falabella y Ripley: ¿Sitios realmente seguros?

Falabella y Ripley son dos “grandes tiendas” que permiten que sus clientes puedan realizar compras online, ambas dicen ser “100% seguras” y están certificadas por VeriSign. El primer error: existe la seguridad al 100% ?

Ambos sitios son vulnerables a ataques Cross-Site Scripting, permitiendo que un atacante use el sitio web de cada tienda para falsificar contenido y robar información o realizar estafas, aprovechandose de la confianza que el usuario tiene en el sitio web.
Los sitios afectados son: https://www.falabella.cl y https://www.ripley.cl incluyendo los sitios “seguros” (https) de cada uno.

Lo más irónico es que los sitios estan “certificados” por una empresa de seguridad que según ellos:

Verisign, líder mundial en certificación de comercio electrónico.

Aunque no me sorprende, luego de haber encontrado hace un tiempo un XSS en el propio sitio web de VeriSign.

Otra cosa que tambien les debería dar verguenza a estas empresas es prometer 100% de seguridad al usuario, como dice en sus propios sitios web:

Todo esto es una mentira.

Seguir leyendo

Cross-Site Scripting en CMS Newtenberg Engine

Esta plataforma de Software permite administrar contenidos y hacer sustentables sitios Web de alta complejidad. Los documentos se almacenan en un reservorio de conocimiento y pueden ser caracterizados según múltiples miradas (clasificandos). Engine apoya las labores de Arquitectura de Información, Modelamiento, Diseño, Poblamiento y Edición de Contenidos, interconectando las labores del equipo de trabajo a través de un sistema de workflow.

La vulnerabilidad está presente en el buscador de este CMS y se replica la mayoría de sus clientes/usuarios.
Se deteca cuando vemos el codigo fuente del buscador, vemos que tiene un atribuo “onsubmit=doSearch()”

Al realizar la busqueda, la función doSearch() nos cambia el href:

function doSearch() {
				// Delete search's cookies
                if( "exists".match ) {
                    var results = document.cookie.match(/\w+=/g);
						if( results ) {
							for( var i=0; i < results.length; i++ ) {
								if( results[i].substring(0,7) == 'search_' ) {
									deleteCookie( results[i].substring(0,results[i].length-1) );
								}
							}
						}
                	}

					setCookie('search_keywords',document.searchForm.keywords.value);
					setCookie('search_start', 0 );
					setCookie('search_group', 0 );
					setCookie('search_expanded', 0 );
					document.location.href="w3-propertyvalue-16131.html"; 
                    return false; 
                } 

Y cuando carga el sitio "w3-propertyvalue...." podemos ver en el codigo fuente que se genera el siguiente javascript:

var url = 'https://ntg-engine.conama.cl/mod/find/cgi/find.cgi?action=query';
	url+= '&engine=SwisheFind';
	url+= '&rpp=';
	url+= '&cid=815';
	url+= '&stid=';
	url+= '&iid=1257';
	url+= '&grclass=resultado-busqueda';
	url+= '&pnid=';
	url+= '&pnid_df=';
	url+= '&pnid_tf=';
	url+= '&pnid_search=2033,1999,1849';
	url+= '&limit=';
	url+= '&searchon=';
	url+= '&channellink=';
	url+= '&articlelink=w3:article';
	url+= '&pvlink=w3:propertyvalue';
	url+= '¬articlecid=';
	url+= '&use_cid_owner_on_links=';
	url+= '&show_ancestors=';
	url+= '&show_pnid=';
	url+= '&cids=815';
	if( "exists".match ) {
		var results = document.cookie.match(/\w+=/g);
		if( results ) {
			for( var i=0; i < results.length; i++ ) {
				if( results[i].substring(0,7) == 'search_' ) {
					url += '&' + results[i].substring(7,results[i].length) + escape( getCookie( results[i].substring(0,results[i].length-1) ) );
				}
			}
		}
	} else {
		url+= '&start=' + getCookie( 'search_start' );
		url+= '&keywords=' + escape(getCookie( 'search_keywords' ));
	}
	url+= '&prepnidtext=' + escape('');
	// Descomentar la siguiente linea para depurar
	//document.write( '<' + 'iframe width="500" height="500" src="' + url + '">' + + '< ' + '/iframe>' );
	url+= '&javascript=1';
	document.write( ' < \/scr' + 'ipt>' );

Esta vulnerabilidad afecta el propio sitio web de la empresa y a casi todos sus clientes.
A partir de este codigo javascript generado por el CMS, construiremos nuestro XSS.

Seguir leyendo

Vulnerabilidad XSS en Prontus CMS

Prontus es un administrador de contenidos web flexible, fácil de usar, robusto y eficiente, con una trayectoria de más de 12 años en el mercado y utilizado por cientos de clientes que lo han aplicado en sus portales corporativos, servicios editoriales y sitios web transaccionales.

Este CMS tiene una vulnerabilidad Cross-Site Scripting que afecta a la mayoría de sus clientes.
Cuando vas a desarrollar un CMS y esperar que muchos usuarios/clientes lo usen, hay que tener cuidado con la seguridad ya que cualquier fallo (bug) o vulnerabilidad puede afectar a todos los que lo utilizan.

Entre los sitios afectados por esta vulnerabilidad estan el sitio web del Senado de la República de Chile, y Fonasa, entre otros.

La vulnerabilidad afecta a todos los sitios creados con Prontus CMS que tengan activo/habilitado el archivo html “antialone.html”

En este archivo encontramos el siguiente codigo javascript:

if (makefs) {
    var ULT_LINK = new Array(); // Usado para volver a portada.
    page = page + '?' + Math.random();
    document.write('<frameset rows="122,1*" frameborder="NO" border="0" framespacing="0">');
    document.write('  <frame name="head" scrolling="NO" noresize src="/prontus_senado/site/edic/base/port/head.html" marginwidth="0" marginheight="0" frameborder="NO">');
    document.write('  <frame name="cont" src="' + page + '" marginwidth="0" marginheight="0">');
    document.write('</frameset>');
  };

Si se fijan, en la linea 6 crea un frame con src=page, y en la linea 3 page=page+?+Math.random(). Por lo tanto, si le pasamos la variable “page” por url con el contenido “javsript:algo…” el navegador lo debería interpretar.

Seguir leyendo