EtiquetaHacking

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

Como NO hacer un captcha: El caso de FeriaMix

Hace tiempo publiqué un XSS en FeriaMix, esta vez les mostraré la ineficiencia de un captcha en el mismo sitio. Todos sabemos que el captcha sirve para detectar que realmente es un humano quien está detrás del teclado y no un bot.

Captcha es el acrónimo de Completely Automated Public Turing test to tell Computers and Humans Apart (Prueba de Turing pública y automática para diferenciar máquinas y humanos).

En el sitio “recuperar contraseña” de FeriaMix pueden ver un captcha que aparentemente es “normal”,

Seguir leyendo

El Phishing y el Banco BBVA Chile

El banco BBVA Chile no se queda atras en sus vulnerabilidades y buscando donde poder reportarlas no he encontrado nada, solo teléfonos donde piden demasiada información personal. No hay ningun formulario ni correo electrónico, por lo que nuevamente se acude a la tecnica de la publicación.

Al igual que lo comentado en el post de El Phishing y el Banco Santander Chile, la idea es dar a conocer como los bancos se lavan las manos con sus campañas anti phishing y anti fraudes, pero no son capaces de ofrecer una plataforma lo suficientemente robusta. Nuevamente este tipo de vulnerabilidades afectan a los usuarios y no al banco directamente, permitiendo el robo de credenciales e información personal, suplantación de identidad, etc.

La vulnerabilidad Cross-Site Scripting detectada se encuentra en la página principal del banco https://www.bbva.cl y corresponde al buscador. El tipoco error de no parsear los parametros de entrada que se pasan por el forumlario o por URL (GET/POST).

La vulnerabilidad no ha sido reportada al banco ya que no se ha encontrado ningun método de contacto, pero se ha publicado en Secureless junto al mismo tipo de vulnerabilidad correspondiente al BBVA de Colombia.

Seguir leyendo

Joomla! Password Cracker

Saber como “hashea” las password el cms Joomla! no es algo muy complicado, no tiene ninguna ciencia y es muy facil de entender para intentar crackear algun password obtenido de alguna base de datos.
El hash en la base de datos tiene la forma de “HASH:SALT” y la forma en que genera el HASH es agregando el SALT al final de la password original, de esta forma: md5(password.SALT):SALT
Por ejemplo, si tenemos la password “foo” y el SALT “bar”, la forma de crear el hash sería:md5(foobar):bar
Lo que quedaría como 3858f62230ac3c915f300c664312c63f:bar

Por ejemplo, para probar con un hash mas real probaremos con  bd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel que corresponde a la password “test” concatenada con el SALT 5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel:

md5(testbd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel) = bd874661cb31eb7b612862725d0008f2

Entonces, la forma de crackear usando por ejemplo un diccionario seria tan facil como “parsear” el SALT, concatenarlo a la palabra del diccionario, calcular su md5 y compararla con el valor que está antes de los “:” del hash. Para esto, hice el siguiente script en Python:

#!/usr/bin/python2

from hashlib import md5
import sys
import string

original = sys.argv[1].split(':')
_md5 = original[0]
_salt = original[1]
print 'Trying to crack ' + _md5 + ' SALTED with ' + _salt + '... '
for line in sys.stdin:
	line = line.strip()
	attempt = md5(line + _salt).hexdigest()
	if(attempt == _md5):
		print _md5 + ':' + _salt + ' --- Password Found: ' + line
		print 'Hapy hacking!'
		sys.exit(0)
print 'Password not found : - ('
sys.exit(1)

Intenemos crackear el hash correspondiente a la password “test”:

$ ./john -i --stdout|python2 joomla-cracker.py bd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel

Trying to crack bd874661cb31eb7b612862725d0008f2 SALTED with 5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel...
bd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel
--- Password Found: test
Hapy hacking!
$

En este caso use “john the ripper” para generar un diccionario en el stdout pasandolo por stdin al script. Tambien se pueden usar diccionarios de la siguiente forma:

$ cat diccionario.txt|python2 joomla-cracker.py bd874661cb31eb7b612862725d0008f2:5LCuch6GA3Du5c3ywjxzlfPvXvvHZQel