EtiquetaSeguridad

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

Búsqueda de servicios DNS con Transferencia de Zona abierta (AXFR)

Ya vimos que los servidores mal configurados que permiten realizar transferencias de zona sin restricciones desde cualquier IP son muchos.

Para saber si un servidor DNS es “vulnerable” a este tipo de ataque usamos la herramienta dig, primero obtenemos los dns que estan asociados al dominio, para este ejemplo usaremos el dominio zerial.org.

$ dig NS zerial.org
; < <>> DiG 9.7.3 < <>> NS zerial.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 64152
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 6

;; QUESTION SECTION:
;zerial.org. IN NS

;; ANSWER SECTION:
zerial.org. 86400 IN NS ns1.linode.com.
zerial.org. 86400 IN NS ns3.linode.com.
zerial.org. 86400 IN NS ns2.linode.com.
zerial.org. 86400 IN NS ns5.linode.com.
zerial.org. 86400 IN NS ns4.linode.com.

Ya tenemos la lista de los servidores dns de zerial.org, para probar la transferencia de zona cambiamos NS por AXFR y forzamos que use el DNS que nosotros elijamos, en este caso probaremos ns3.linode.com:

$ dig AXFR zerial.org @ns3.linode.com

; < <>> DiG 9.7.3 < <>> AXFR zerial.org @ns3.linode.com
;; global options: +cmd
; Transfer failed.

Failed. No hemos logrado transferir la zona desde ns3.linode.com, lo que nos indica que aparentemente se encuentra bien configurado.
Otro ejemplo usando un dominio que sepamos que tiene esta falla: finanzas.gov.ar.
Obtenemos los dos:

$ dig NS finanzas.gov.ar

; < <>> DiG 9.8.0-P4 < <>> NS finanzas.gov.ar
;; global options: +cmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 38476
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;finanzas.gov.ar. IN NS

;; ANSWER SECTION:
finanzas.gov.ar. 7006 IN NS ns3.zoneedit.com.
finanzas.gov.ar. 7006 IN NS ns9.zoneedit.com.

Probamos el segundo dns, ns9.zoneedit.com.

$ dig AXFR finanzas.gov.ar @ns9.zoneedit.com

; < <>> DiG 9.8.0-P4 < <>> AXFR finanzas.gov.ar @ns9.zoneedit.com
;; global options: +cmd
finanzas.gov.ar. 7200 IN SOA ns3.zoneedit.com. soacontact.zoneedit.com. 2011266765 2400 360 1209600 300
finanzas.gov.ar. 7200 IN NS ns3.zoneedit.com.
finanzas.gov.ar. 7200 IN NS ns9.zoneedit.com.
finanzas.gov.ar. 7200 IN A 201.253.123.35
finanzas.gov.ar. 7200 IN MX 10 ALT1.ASPMX.L.GOOGLE.COM.
finanzas.gov.ar. 7200 IN MX 10 ALT2.ASPMX.L.GOOGLE.COM.
finanzas.gov.ar. 7200 IN MX 0 ASPMX.L.GOOGLE.COM.
finanzas.gov.ar. 7200 IN MX 20 ASPMX2.GOOGLEMAIL.COM.
finanzas.gov.ar. 7200 IN MX 20 ASPMX3.GOOGLEMAIL.COM.
finanzas.gov.ar. 7200 IN MX 20 ASPMX4.GOOGLEMAIL.COM.
finanzas.gov.ar. 7200 IN MX 20 ASPMX5.GOOGLEMAIL.COM.
mail.finanzas.gov.ar. 7200 IN CNAME ghs.google.com.
googleffffffff85ca3fa2.finanzas.gov.ar. 7200 IN CNAME google.com.
asignaciones.finanzas.gov.ar. 7200 IN A 186.136.205.252
docs.finanzas.gov.ar. 7200 IN CNAME ghs.google.com.
www.finanzas.gov.ar. 7200 IN A 201.253.123.35
mapas.finanzas.gov.ar. 7200 IN A 201.253.123.35
finanzas.gov.ar. 7200 IN SOA ns3.zoneedit.com. soacontact.zoneedit.com. 2011266765 2400 360 1209600 300
;; Query time: 355 msec
;; SERVER: 66.240.231.42#53(66.240.231.42)
;; WHEN: Thu Aug 11 13:49:31 2011
;; XFR size: 18 records (messages 18, bytes 1138)

La transferencia de zona se hizo de forma exitosa.

Para poder analizar de forma automatica un listado de dominios, hice un script en bash que usa DIG para obtener los dns de cada dominio y prueba realizar AXFR por cada dominio en todos sus dns.

#!/bin/bash

digcmd=$(which dig)
domain=$1
echo -n "[+] Getting NS domains from $1 ..."
ns_domains=$(dig NS $domain @4.2.2.2|grep ^$domain|awk {'print $5'}|sed 's/.$//g')
echo -e "\t[OK]"
for ns in $ns_domains; do echo "[-] Found: "$ns; done
for ns in $ns_domains
do
	echo -n "Trying Zone Transfer from $ns: "
	$digcmd AXFR $domain @$ns|egrep 'Transfer failed|timed out|end of file'>/dev/null
	if [ $? -eq 1 ]
	then
		echo -e "\tSuccess."
	else
		echo -e "\tFail."
	fi
done

Seguir leyendo

AXFR: Una vulnerabilidad que pasa desapercibida …

Las transferencias de zona en los servidores de DNS en simples palabras se usa para replicar lo que hay en un maestro hacia su escalvo. Si esta caracteristica se encuentra mal configurada podria ser usada por un atacante para obtener información sensible sobre el dominio.
Un servidor maestro debe filtrar por dirección IP qué esclavos pueden realizar transferencias, si esto no se configura correctamente entonces cualquier atacante podría consultar por las zonas de los dominios que administra.

imagen: https://getglue.com/topics/p/dns_zone_transfer

Las transferencias de zona se realizan mediante AXFR, que según su descripción:

Las siglas AXFR hace referencia a la transferencia por zonas de un DNS primario a un DNS secundario o de un DNS primario a un server maestro y de un server maestro a un DNS secundario, si llegara a existir algún problema de configuración o actualización del software de cualquiera de estos servidores se podrían explotar una serie de vulnerabilidades como por ejemplo un DoS y la integridad y confidencialidad de la base de datos del DNS primario se verían comprometidas, se estima que alrededor de un 60% de los servidores DNS en internet son vulnerables.

(Fuente: https://es.wikipedia.org/wiki/AXFR)

Tambien exsite la transferencia de zona incremental (IXFR).

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

Vulnerabilidad SQL Injection + Cross-Site Scripting en sitio web del CLCERT

Según el propio sitio web:

El CLCERT tiene como misión monitorear y analizar los problemas de seguridad de los sistemas computacionales en Chile, y reducir la cantidad de incidentes de seguridad perpetrados desde y hacia éstos.

Si bien CLCERT es una “organización” que busca mejorar la seguridad, creo que es impresentable que tengan publicados sitios web con vulnerabilidades tan basicas.
Esta organización da cursos y diplomados relacionados a la “Seguridad Computacional” o como la mayoría los conoce “Cursos de Seguridad Informática” o simplemente “Cursos de Seguridad”. Todas las personas que han pasado por estos cursos se pueden ver en la URL https://capacita.clcert.cl/dir/ la cual con tiene una vulnerabilidad de SQL Injection, posibilitando al atacante obtener más información sobre las personas asistentes a los cursos o bien obtener información del servidor.

La vulnerabilidad SQL Injection se produce al no parsear los parametros pasados por GET mediante la variable “apellido”, “id” y “fecha” del archivo index.php. Y la XSS se produce a partir de esta misma.

Si navegan por el sitio y comienzan a ver las URL se darán cuenta de forma fácil que parámetro o url es la vulnerable. Por ejemplo, si nos situamos por encima de una letra, podemos ver la url

Deducimos que podemos inyectar código sql mediante la variable “apellido“.

Seguir leyendo