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 = 'http://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+= '&notarticlecid=';
	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.

Para este ejemplo, lo que nos interesa es el valor final de la variable “url”, que en este caso es algo similar a:

http://ntg-engine.conama.cl/mod/find/cgi/find.cgi?action=query&engine=SwisheFind&rpp=&cid=815&stid=&iid=1257&grclass=resultado-busqueda&pnid=&pnid_df=&pnid_tf=&pnid_search=2033,1999,1849&limit=&searchon=&channellink=&articlelink=w3:article&pvlink=w3:propertyvalue&notarticlecid=&use_cid_owner_on_links=&show_ancestors=&show_pnid=&cids=815&keywords=prueba

Ya nos salimos del dominio conama.cl y entramos a jugar al subdominio ntg-engine.conama.cl, donde está instalado el motor (engine) del CMS. Si abrimos la URL de prueba, podemos ver el siguiente resultado:

Aparece en negrita la palabra que buscamos. Si en lugar de prueba insertamos un codigo javascript, será ejecutado:

Los sitios afectados son:

Newtenberg – http://www.newtenberg.com
SINIA (Sistema Nacional de Informacion Ambiental) – http://www.sinia.cl
Ministerio del Medio Ambiente – http://www.mma.gob.cl
Superintendencia de Servicios Sanitarios – http://www.siss.gob.cl
Repositorio Institucional CONICYT – http://ri.conicyt.cl
Red Lideres – http://www.redlideres.cl
Punto Lex – http://www.puntolex.cl
Subsecretaria de Desarrollo Regional y Administrativo – http://www.subdere.gov.cl
CONAMA – http://www.conama.cl
El Periodista – http://www.elperiodista.cl/
Colombia Aprende – http://www.colombiaaprende.edu.co

Cada uno de estos sitios construye su propia URL dependiendo de los parametros, cuando hagamos una busqueda y veamos el codigo fuente, podemos ver el javascript generado automaticamente y crear nuestra URL explotable a partir de la variable “url”.

PoC Subsecretaria de Desarrollo Regional y Administrativo (SUBDERE)

URL: http://engine.subdere.gov.cl/mod/find/cgi/find.cgi?action=query&engine=&rpp=20&cid=876&stid=&iid=1510&grclass=&pnid=&pnid_df=&pnid_tf=&pnid_search=2403,2400,2444,2460,2530,2570,2544,2569,2541,2571&limit=&searchon=&channellink=&articlelink=w3:article&pvlink=w3:propertyvalue&notarticlecid=&use_cid_owner_on_links=&show_ancestors=1&show_pnid=1&cids=876&keywords=%3Cscript%3Ealert%28/XSS%20PoC/%29%3C/script%3E

PoC en el propio sitio de Newtenberg

URL: http://engine.newtenberg.com/mod/find/cgi/find.cgi?action=query&engine=SwisheFind&rpp=10&cid=924&stid=5686&iid=1765&grclass=resultadobusqueda&pnid=&pnid_df=&pnid_tf=&pnid_search=&limit=&searchon=&channellink=&articlelink=&pvlink=&notarticlecid=0&use_cid_owner_on_links=0&show_ancestors=&show_pnid=&cids=924&keywords=%3Cscript%3Ealert%28/XSS%20PoC/%29%3C/script%3E

El error se produce al no filtrar el contenido de la variable “keywords“.

No se descarta que puedan haber mas sitios afectados.

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

pero fijense en un detalle, cuando escriben mal la palabra que aparece en el captcha y le dan al boton “continuar”, salta automaticamente una alerta en javascript diciendo que el captcha no es valido.

Con esto podemos deducir que se hace la validación del captcha antes de que se envie la información al servidor, por lo tanto, es posible vulnerarlo. Si revisamos el codigo javascript encontramos “jcap.js” el cual contiene una validacion demasiado basica e insegura.

Sorpresa! La imagen del captcha que ustedes ven no es autogenerada, sino una imagen con una palabra estatica!

La imagen “71.jpg” tiene la palabra “mine”, la 72 tiene otra palabra y asi hasta la 191.jpg. Si van al directorio de “/jcap/cimg/” podran ver un listado de todas las imagenes del captcha.

De esta forma es tan facil como hacer un bot que se conecte, obtenga el nombre de la imagen y segun el “numero” de imagen, escriba una palabra predeterminada.

Se puede llamar CAPTCHA a esto?

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 http://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.

El script vulnerable corresponde a http://www.bbva.cl/tlch/jsp/ch/esp/meta/buscador/buscar.jsp que pasandole los parametros necesarios es posible ejecutar código javascript o html mediante la variable q.

Las politicas de seguridad del banco dicen textualmente:

Permitiendo este tipo de ataques (xss) el banco no está cumpliendo, ya que un atacante puede suplantar la identidad del sitio y abusar de la confianza que tiene el usuario/cliente en el sitio web del BBVA, pudiendo interceptar el tráfico, generar formularios falsos, redireccionar al usuario a sitios malignos, etc.

Nuevamente, este es un llamado para que los bancos se hagan cargo de este tipo de cosas!

Editado: (13 de Junio del 2011) La vulnerabilidad se encuentra corregida. El banco no respondio ningun email y tampoco dio ningun tipo de comunicado o mensaje al respecto.

Con esta vulnerabilidad es posible robar información sensible y suplantar la identidad del usuario.

Justo en la fecha de la devolución de impuestos aparece esta vulnerabilidad en el login del sistema. Permite redireccionar a un usuario, luego de logearse, a cualquier sitio e incluso permite el robo de cookies mediante ejecución arbitraria de javascript en el cliente.

La URL vulnerable es https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html que al agregarle al final “?http://alguna_url“, el usuario luego de iniciar sesión será redirigido hacia esa URL. Por ejemplo:

https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html?https://www.google.com

Luego de ingresar, seremos redirigidos a Google.

Tambien puede ser un javascript, por ejemplo mostrando las cookies de sesión:

O por ejemplo, usar javascript para dibujar un formulario que haga POST a un sitio remoto, capturando la información:

https://zeus.sii.cl/AUT2000/InicioAutenticacion/IngresoRutClave.html?javascript:document.write%28%27%3Cform%20method=post%20action=%3Eusuario:%20%3Cinput%20type=text%3E%3Cbr%3Epass:%20%3Cinput%20type=password%3E%3Cbr%3E%3Cinput%20type=submit%20value=entrar%3E%27%29;

Abusando de la confianza que tiene el usuario sobre el sitio, con certificado SSL válido. De esta forma es posible obtener información confidencial de los usuarios, de forma transparente.

Nuevamente los sistemas informáticos dejan mucho que desear. Esta vulnerabilidad fue reportada la semana pasada mediante el formulario de contacto (el único medio disponible) pero no se obtuvo respuesta.

Hace unos meses reporté una vulnerabilidad XSS en la banca de personas del Banco Santander, la cual no ha sido corregida. Ahora, segun la campaña anunciada por parte de Secureless, retomaré este mismo bug y aprovecharé de reportar otros que hemos encontrado, además preparé unas pruebas de concepto para dejar en claro que podemos hacer y que no, explotando estas vulnerabilidades donde los unicos afectados son los clientes usuarios.

Las vulnerabilidades detectadas son del tipo XSS, encontradas en el sistema de clientes (banca de personas) y en el sitio web público.

Los scripts o urls vulnerables son:

• https://www.santander.cl/transa/errores/PagError.asp
• https://www.santander.cl/transa/productos/tc_conti/PAMPA/pcpMosTjc.asp
• https://www.santander.cl/transa/preerror.asp

Las tres con certificado ssl, permitiendo aprovecharse de la confianza que tiene el usuario sobre el sitio.

Como primera prueba de concepto, inyectaré un código html que permita crear un iframe dentro del sitio, mostrando información de un sitio remoto distinto al Santander, que perfectamente podria ser un sitio malicioso.

En este caso, en mi servidor tengo un archivo “PoC.html” y he accedido a el desde el dominio santander.cl. De esta forma podemos incluir en ese iframe un sitio que tenga una copia exacta del banco, usando el dominio de santander y la confianza del usuario.

El siguiente ejercicio, será el secuestro de cookies. El primer paso es ver la cookie usando un simple “alert” en javascript:

El primer pantallazo corresponde a una de las URL que no necesita estar logeado, el segundo es con la sesión iniciada.

Ahora enviaremos esa cookie a un servidor externo, inyectando el siguiente script:

Y recibiendolo en mi servidor con un simple script en php que lea la variable “cookie” pasada por GET.
En el caso de no estar con la sesion iniciada, veremos algo asi:

Cuando iniciemos sesion, fijense el cambio:

El IDLOGIN cambia.

Finalmente, podemos lograr algo asi:

En la URL https://www.santander.cl se visualiza el sitio de http://www.bancoestado.cl, con un simple iframe pasado por GET a la variable y script vulnerable.

Perfectamente un atacante podria realizar algo similar, con un sitio completamente falso que se dedicara a obtener información, pedir usuario, contraseña, etc.

En Chile, los bancos tienen una campaña contra el phishing donde se limitan a entregar manuales y decir “no ingreses tus datos donde no debes”, pero realmente no se preocupan de tener mecanismos de validación y protección, permitiendo que cualquier persona pueda suplantar su identidad y usar la confianza que tiene el usuario en el sitio.
Existe un sitio llamado “avispate.cl“, que supuestamente es para hacer un llamado a la gente y educar para que no caigan en este tipo de trampas y no entreguen información a cualquier sitio.

Bien, por un lado tenemos que los usuarios entregan información a personas que no corresponden, que caen en las trampas pero por otro lado, algo que es claramente responsabilidad del banco: Hacer que sus sitios y sistemas sean 100% seguros!

Los bancos en lugar de ayudar a los usuarios y prevenir este tipo de ataques, prefieren cobrar:

En secureless, comenzamos a trabajar en una investigación en busca de vulnerabilidades XSS, CSRF y otras que puedan afectar directamente al usuario. Nuestro propósito es dejar en claro que los bancos deben ser competentes y responder por las fallas de seguridad que tienen. Hasta ahora, según nosotros, como este tipo de vulnerabilidades no les afecta a ellos, sino que afecta a los clientes, entonces no se preocupan lo suficiente.
El proyecto consiste en publicar estas vulnerabilidades diariamente durante un par de dias, demostrar y dejar al descubierto este tipo de negligencia. Comenzaremos por Chile, luego seguiremos atacando bancos de otros paises.

Sobre XSS y CSRF …

Las vulnerabilidades XSS permiten realizar modificaciones en los sitios web por el lado del cliente, cuando una entidad bancaria con certificado ssl (https) tiene este tipo de vulnerabilidad, se combierte en un sitio potencial para ser atacado y sus usuarios los afectados. Por ejemplo, si un sitio permite inyectar código html o javascript, facilmente podriamos poner un iframe que ocupe todo el ancho y alto del navegador, y que el usuario no se de cuenta que está visitando a otra página.

Por otro lado tenemos los ataques CSRF, que combinado con XSS, practicamente es posible hacer lo que queramos con el usuario: llevarlo de un sitio a otro, pasar parametros de un sitio falso a uno verdadero, etc.

Marcar la división entre los archivos

Para saber exactamente el byte donde debemos cortar con split el archivo para poder separarlo, vamos a agregar, al final de nuestro archivo ofuscado, una linea en texto plano con un numero X = bytes. Puede sonar absurdo por lo simple que es, pero es posible.

¿Cómo hacerlo? Es muy simple, tambien usamos echo:
$ echo XXXX >>archivo_ofuscado.jpg"
Donde XXXXX corresponde a la cantidad de bytes que la puedes saber por ejemplo con “ls -l” sobre el archivo.

Entonces el procedimiento para “separar” los archivos sería leer la última línea del archivo y hacer un split -b XXXX.

Ya habiendo aprendido a ocultar y a encontrar archivos, podemos automatizarlo y usar el siguiente script:

esconder.sh

#!/bin/bash

if [ $# -eq 3 ]; then
        separador=$(ls -l $1|awk -F ' ' '{print $5}');
        cat $1 $2 > $3
        echo -e "\n$separador" >>$3
        echo "Archivo $3 creado.";
else
        echo "Sintaxis: $0 archivo1 archivo2 salida"
        exit 1;
fi

encontrar.sh

#!/bin/bash

if [ $# -eq 1 ]; then
        separador=$(tail -1 $1);
        sed -i 's/^$separador$//g' $1
        split -b $separador $1
else
        echo "Sintaxis: $0 archivo"
fi

Pueden descargar los scripts desde aca:
* esconder.sh.gz (4Kb)
* encontrar.sh.gz (4Kb)

Como pueden ver, para esconder archivos y poder “separarlos”, ya sea para enviar informacion ilegible o escondida a otras personas basta con saber usar algunos comandos basicos de unix. Si bien no es una forma an “profesional” de hacerlo, es muy simple y no se necesita un programa robusto, simplemente un par de líneas en bash.

Para separar el archivo vamos a usar el comando split, que nos permite “dividir” o “cortar” un archivo por líneas, bytes, etc. En este caso, separaremos por bytes el archivo.
La sintaxis de split para separar un archivo es tan simple como:

$ split --bytes=XXX archivo
o tambien
$ split -b XXX archivo

De esta forma, el split separará el archivo cada XXX bytes, creando archivos de la forma xab, xac, xad, … xaN.
Ejemplo:
[zerial@balcebu ejemplo_split]$ du -sh archivo.jpg
48K archivo.jpg
[zerial@balcebu ejemplo_split]$ split -b 10000 archivo.jpg
[zerial@balcebu ejemplo_split]$ ls
archivo.jpg xaa xab xac xad xae
[zerial@balcebu ejemplo_split]$ du -csh *
48K archivo.jpg
12K xaa
12K xab
12K xac
12K xad
8.0K xae
104K total
[zerial@balcebu ejemplo_split]$

Para poder separar el archivo ofuscado, vamos a necesitar saber de antemano el tamaño del archivo original, para poder separarlo por esa cantidad de bytes.

Siguiendo con el mismo ejemplo del primer post, aquí vamos:

Tenemos los tres archivos; el archivo principal, el archivo que queremos ofuscar y el archivo ya ofuscado
[zerial@balcebu ofuscar]$ ls -l
total 816
-rw-r--r-- 1 zerial users 408482 Oct 27 09:54 archivo.zip
-rw-r--r-- 1 zerial users 414523 Oct 27 09:54 archivo_ofuscado.jpg
-rw-r--r-- 1 zerial users 6041 Oct 27 09:52 dummie.jpg
[zerial@balcebu ofuscar]$

Nuestro fin es separar el archivo “archivo.zip” de “archivo_ofuscado.jpg”.
[zerial@balcebu ofuscar]$ mv archivo_ofuscado.jpg separacion/
[zerial@balcebu ofuscar]$ cd separacion/
[zerial@balcebu separacion]$ ls
archivo_ofuscado.jpg
[zerial@balcebu separacion]$

Vemos el tamaño en bytes del archivo principal “dummie.jpg”
-rw-r--r-- 1 zerial users 6041 Oct 27 09:52 dummie.jpg

6041 bytes. Por tanto, tenemos que decirle a split, que nos divida el archivo_ofuscado.jpg en pequeños trozos de 6041 bytes cada uno.

[zerial@balcebu separacion]$ split -b 6041 archivo_ofuscado.jpg
[zerial@balcebu separacion]$ ls -l
total 956
-rw-r--r-- 1 zerial users 414523 Oct 27 09:54 archivo_ofuscado.jpg
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xaa
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xab
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xac
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xad
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xae
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xaf
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xag
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xah
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xai
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xaj
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xak
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xal
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xam
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xan
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xao
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xap
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xaq
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xar
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xas
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xat
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xau
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xav
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xaw
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xax
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xay
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xaz
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xba
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbb
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbc
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbd
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbe
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbf
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbg
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbh
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbi
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbj
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbk
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbl
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbm
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbn
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbo
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbp
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbq
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbr
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbs
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbt
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbu
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbv
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbw
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbx
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xby
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xbz
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xca
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcb
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcc
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcd
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xce
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcf
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcg
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xch
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xci
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcj
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xck
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcl
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcm
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcn
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xco
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 xcp
-rw-r--r-- 1 zerial users 3735 Nov 19 10:57 xcq
[zerial@balcebu separacion]$

Ya tenemos dividido el archivo_ofuscado en pequeños trozos. Como nuestro archivo dummie.jpg teina un tamaño de 6041 bytes y es este archivo el que está por sobre el archivo ofuscado, el primer archivo que nos extrajo split corresponde a dummie.jpg; por tanto, renombramos xaa a dummie.jpg y concatenamos todos los demas archivos y lo llamamos archivo.zip (corresponde a nuestro archivo ofuscado)

[zerial@balcebu separacion]$ mv xaa dummie.jpg
[zerial@balcebu separacion]$ cat x* >archivo.zip
[zerial@balcebu separacion]$ rm x*
[zerial@balcebu separacion]$ ls -l
total 816
-rw-r--r-- 1 zerial users 408482 Nov 19 10:59 archivo.zip
-rw-r--r-- 1 zerial users 414523 Oct 27 09:54 archivo_ofuscado.jpg
-rw-r--r-- 1 zerial users 6041 Nov 19 10:57 dummie.jpg
[zerial@balcebu separacion]$

Con esto ya hemos extraído nuestro archivo ofuscado. Para comparar que está íntegro y que realmente corresponde al original, comparemos los md5:

5c29dbb3975a5ffe31768b79548e1884 archivo.zip
ded467af5a22134c44da18bc8d4fed1b dummie.jpg
5c29dbb3975a5ffe31768b79548e1884 ../archivo.zip
ded467af5a22134c44da18bc8d4fed1b ../dummie.jpg

Los dos primeros archivos corresponden a los archivos extraídos con split y los dos últimos a los archivos originales. Los md5 coinciden, por lo que lo hemos conseguido. Si ahora unzipeamos nuestro archivo.zip, no nos mostrará ningun warning, lo mismo pasara con winrar, etc.

[zerial@balcebu separacion]$ unzip archivo.zip
Archive: archivo.zip
creating: tipografias/
inflating: tipografias/Aller_Bd.ttf
inflating: tipografias/Aller_BdIt.ttf
inflating: tipografias/Aller_It.ttf
inflating: tipografias/Aller_Lt.ttf
inflating: tipografias/Aller_LtIt.ttf
inflating: tipografias/Aller_Rg.ttf
inflating: tipografias/AllerDisplay.ttf
[zerial@balcebu separacion]$

Sin warnings ni errores.

En el hackmeeting realizado en La Paz, Bolivia, se exhibieron distintos temas relacionados a la seguridad informatica/hacking y electrónica. Se realizaron conferencias, debates/mesas redondas y tambien otro tipo de actividades denominadas “hacktividades”, donde nos reuniamos a participar intentando vulnerar sistemas o simplemente discutiendo y aportando todos de forma colaborativa sobre un tema en especifico.

Se realizaron charlas relacionadas a Spoofing, redes Mesh, Ofuscación de archivos, Micro controladores, entre otros. Se discutieron temas relacionados a la seguridad informática, las leyes y la poca preocupación por el gobierno en estos temas. Hacktividades tales como un concurso de programación y “intrusion and defacing” en sitios bolivianos.

Todas las charlas fueron grabadas y en cuanto pueda las subiré para que puedan descargarlas.

Los horarios son los siguientes:
Sabado 9 de Octubre
- 19:15 hrs: Hacking automatizado
Domingo 10 de Octubre
- 15:00 hrs: Ofuscación de archivos

Les recuerdo que la entrada es liberada.

El próximo 9 y 10 de Octubre se celebrará en Kernelhouse el hackmeeting correspondiente al año 2010. Habrán charlas, talleres y debates relacionadas con la seguridad informática y libertades.

el sitio de sym es vulnerable a todo a proposito y les encuentro razón mi casa tiene las puertas abiertas pero si robas pagas.

En fín … Unos dias despues, se contacto conmigo Rodolfo Berrios, diseñador y encargado del sitio web, consultandome por las vulnerabilidades encontradas. Cuando intenté reproducir la vulnerabilidad XSS me encontré con la sorpresa de que ya estaba corregida! Sin embargo, no se corrigió del todo, ya que si bien no me dejaba inyectar código JavaScript, si me dejaba inyectar html

Esto pasa al no controlar los parametros pasados por GET, en este caso los parametros de busqueda, un usuario al buscar algo puede escribir codigo html arbitrario.

La URL vulnerable es:

http://www.sym.cl/busqueda/?palabras=%22%3Eb+<aca codigo html>

El problema ya está reportado y se está esperando una solución.

Phishing es un término informático que denomina un tipo de delito encuadrado dentro del ámbito de las estafas cibernéticas, y que se comete mediante el uso de un tipo de ingeniería social caracterizado por intentar adquirir información confidencial de forma fraudulenta (como puede ser una contraseña o información detallada sobre tarjetas de crédito u otra información bancaria).

Como dice la definición, son técnicas que se aplican mediante ingeniería social y ésta es, por si misma, un arte.
Podemos detectar distintos tipos de phishing, desde uno muy simple como falsificar un sitio y lanzarlo al mundo para que la gente caiga o bien uno más complejo con objetivos determinados y con víctimas específicas. En el primer tipo, me gustaría hacer referencia a todos los conocidos ataques que se han hecho a bancos simplemente falsificando el sitio web y obteniendo información de gente al azar, por ejemplo el caso en que se vio envuelto Mastercard Argentina. Con el segundo tipo, quiero hacer referencia a casos más trascendentes que generalmente no son conocidos, ya que no afectan a mucha gente sino mas bien a una víctima específica. Para mi, el primer tipo es una mierda, sin embargo, me gustaría destacar los ataques del segúndo tipo. De ahora en adelante, los distinguiré según su tipo.

Primero, voy a entrar en detalles con el phishing de primer tipo. Cualquier persona con mínimos conocimientos en desarrollo puede copiar una página y conseguirse un dominio similar al original para hospedarla y lanzarla al mundo para ver quienes caen, generalmente con estos tipos de ataques no sabes quienes son las personas que caen en tu trampa, simplemente obtienes sus datos para fastidiarles, ingresas a sus cuentas y ver si tiene algo entretenido, no tiene ninguna ciencia. Este tipo de ataques no tienen ningún sentido, no se está aplicando ingeniería social ni mucho menos.
Existe una gran diferencia entre dirigir los ataques a una persona o víctima en particular versus el direccionarlo a quien caiga: la dificultad y la emoción.

El segúndo tipo es en el que quiero profundizar más. Cuando tenemos una víctima en la mira, es mucho más emocionando hacer éste tipo de ataques, ya que nos costará más y nuestro fín es único, no afectará a otras personas quienes no nos interesa. Para hacer ataques dirigidos, tenemos distintas técnicas, desde ataques locales hasta ataques remotos, podemos hacernos pasar por otra persona, engañando a nuestra víctima para que crea lo que nosotros queremos que crea y así obtener lo que queremos, hasta podemos manipularla. La víctima debe pensar que somos alguien de confianza, que se mueve dentro de su círculo de amigos o conocidos, sabemos mucho de ella y ella cree saber mucho de nosotros. Hacer que la víctima confíe en nosotros toma mucho tiempo, hace que haga lo que nosotros queremos más aún. Se puede lograr desde ataques sicológicos hasta con ataques netamente informáticos pero sin duda lo mejor es una combinación de ambos. Generalmente las víctimas de éste tipo de ataque son conocidos (nosotros lo conocemos, pero muchas veces él a nosotros no) a menos que sea por encargo.
La captura de datos o información se puede lograr falsificando websites, por teléfono, en persona, mediante algun tipo de mensajería instantanea, sniffeando la red, etc. Todo va a depender de nuestra imaginación, conocimiento y capacidades.

Cuando tenemos una víctima elegida, es muy entretenido el proceso en el cual hay que seducirla y mucho más aún, cuando la persona cae en nuestro juego y una véz obtenida la información es mucho más emocionante aún. Luego es el proceso de la verificación de información y posteriormente, una des-seducción de nuestra víctima, es decir, hacer que poco a poco se vaya alejando, pero sin perder el control de la situación y obviamente, sin pretender que nuestro objetivo se de cuenta de lo que planeamos hacer. Lo mejor es confundirlo.
No siempre se logra el objetivo, aveces porque nuestras técnicas han fallado y otras veces porque la persona que elegimos como víctima no es tan fácil de seducir. Hay que saber en qué momento abortar misión, porque los afectados podemos ser nosotros.

Existe un concepto errado de lo que es el phishing, al igual que muchas cosas, la popularidad de los términos terminan deformandose. Para mucha gente éste término es sinónimo de “robo de cuenta del banco y transferencias de dinero ilícitas“, que sería la definición peyorativa.
Detrás de muchos hackeos existen, implícita o explícitamente, técnicas de phishing aplicadas sobre las víctimas, y no podemos desperdiciar todo el proceso pensante y las capacidades del atacante para elaborar un ataque de ésta magnitud.

La idea de este post es explicarles, en base a mi experiencia, ambas técnicas. En especial la segunda. Existen muchas empresas que exhiben su red en una señal wifi pública con cifrado WEP y es por esto que quiero dar mayor énfasis a éste tipo de penetración.

En el primer caso, tenemos el ingreso al servidor objetivo mediante alguna vulnerabilidad en los sitios o servicios que hospeda nuestra víctima. En este ejemplo, sólo me referiré al servicio http.
El esquema es mas o menos así:

Lo que quiero explicar es muy simple, tenemos ese portatil que seriamos nosotros, los atacantes, y en el recuadro celeste, los servidores conectados en una red de área local (lan) o en una zona desmilitarizada (dmz). La idea es ingresar a ese recuadro celeste sea como sea, aprovechandose de algun servidor mal configurado o sitio que exponga alguna vulnerabilidad y, cuando estemos dentro, empezar a saltar a los otros servidores y ganar acceso poco a poco a toda la red. Una vez que tengamos acceso a uno de los servidores dentro del área celeste, podremos usar herramientas para detectar otras máquinas, por ejemplo el conocido nmap. Con ésta herramienta, podremos escanear segmentos y subsegmentos completos, hacer pings a múltiples direcciones y a distintos servicios y detectar cosas como la mac de cada equipo, servicios que ofrecen, hostname, etc.

Ahora quiero pasar al punto dos, que es lo que más me gusta.

El cifrado WEP es muy vulnerable y muy fácil de crackear, ya sea 64 o 128bits, en un par de minutos es posible obtener la contraseña. Aunque existen métodos de cifrado como WPA que son mucho más seguros y requiere un diccionario para lograr descifrar la contraseña, lo que hace que sea poco probable de hacerlo.
Bueno, teniendo en cuenta todos estos antecedendes resulta increible que aún existan empresas u organismos (inclusive del gobierno) que estén exponiendo su red vía wifi con cifrado WEP. Pero para nosotros, esto es bueno, ya que nos podemos aprovechar ya sea para obtener internet free o para lo que queramos hacer

Cuando nos logramos conectar a una red wifi de una empresa, la cual está mal configurada y si a ésto, sumamos que el firewall (si es que tienen) está casi configurado por defecto, es todo mucho más fácil. Existen casos en que subsegmentan y dividen la red por departamento o bien aislan los servidores de los pc de escritorio, pero lo hacen solo cambiandoles las direcciones ip, muchas veces ni si quiera crean reglas en el firewall para que estas maquinas no se puedan ver o bien crear una zona desmilitarizada para los servidores. Cuando ésto sucede, nosotros lo único que debemos hacer es camiarnos la IP a una que esté dentro del rango y listo, ya somos parte de “la red de servidores”. Para descubrir que rango de IP debemos usar para ir cambiando de departamento o para ingresar a zonas “privilegiadas”, podemos utilizar la misma herramienta que propuse en el punto 1: nmap. Tambien podemos utilizar algún sniffer como wireshark o ettercap para descubrir información interesante.

Existe el caso donde los servidores no están alojados fisicamente en la misma empresa, pero perfectamente con un poco de ingenio e imaginación podemos obtener la información de acceso a los servidores estándo dentro de la red, filtrando y analizando la informaicón, por ejemplo realizando un ataque MiTM, envenenando la red. Cuando ya formamos parte de la red, es mucho más fácil analizar el tráfico de la red, escanear máquinas e intentar ganar accesos a alguna de ellas y con una red wifi “protegida” con WEP no nos deberíamos tardar más de 1 hora en hacerlo.

Cuando empezamos a escanear nos encontramos con varias sorpresas, desktop con windows, servidores ftp, servidores de impresion, routers sin clave, etc. Nos podemos divertir un rato mandando a imprimir algunos mensajes, enviando mensajes dentro de la red de windows (el típico winpopup ó net send). Es muy típico encontrarse accesos a Terminal Servers, directorios compartidos con Samba (incluso computadores enteros compartidos con Samba), etc.

La respuesta a primera vista sería “Es imposible, ya que sólo tiene permitido ingresar desde localhost y, generalmente, el puerto no está a la escucha de 0.0.0.0” pero si vamos más allá y tenemos un poco de imaginación, podemos llegar a pensar de que si es posible; jugando un poco con los conceptos y aplicando distintas técnicas de penetración y de búsqueda de vulnerabilidades que nos lo permitan.

La idea de ingresar “remotamente” queda descartada si pensamos en conectarnos directamente a la base de datos desde un client externo, pero podemos pensarlo cómo el hecho de lograr acceder (remotamente) de una u otra forma para lograr la conexion con el host. Por ejemplo, subiendo un fichero php que tenga las líneas necesarias para conectarse a la base de datos y hacer lo que necesitemos.

No vamos a usar fuerza bruta ni técnicas de robo de información, simplemente nos aprovecharemos de algunas vulnerabilidades comunes.

Existen muchas vulnerabilidades que nos van a permitir ejecutar algún tipo de código arbitrario de manera tal de poder conectarnos a la base de datos a nuestra manera. A continuación enumeraré las distintas vulnerabildiades que nos podrían permitir lograr nuestro objetivo.

• Remote Code Execution (RCE): Mediante ejecución de código remoto, es posible manejar arbitrariamente una conexión a la base de datos y de esta forma obtener y/o modificar los datos que nos interesan. Esta técnica podría permitir al atacante tener un control total sobre la base de datos del usuario en cuestión. Podemos ejecutar comandos como mysqldump o pg_dump en el caso de mysql o postgres, respectivamente. Tambien podemos ejecutar código php usando el la interfáz de línea de comandos (php-cli), python, perl, etc.
• Local|Remote File Include (L|RCI): Incluyendo ficheros remotos tambien es posible ejecutar código arbitrariamente, tal cómo lo describí en el punto anterior. Podemos escribir un script en php que nos haga un dump de la base de datos y que la deje en un directorio al cual tengamos acceso desde internet para luego poder descarga la información. Tambien se puede usar usando la técnica de inclusión de ficheros locale, siempre y cuando tengamos algún tipo de acceso para lograr subir ese fichero (cómo lo que explicaré en el próximo punto).
• File Upload by Authentication Bypass: Esta vulnerabilidad es muy común (lo digo por experiencia) y corresponde nada más ni nada menos al hecho de ingresar en un sistema de gestión de contenido y/o usuarios, el cual permita subir algún archivo sin validarlo (o validandolo incorrectamente). Por ejemplo, típico sistema de gestión de usuario que nos permite adjuntar un curriculum, imágen o sistema de gestión de contenido que nos permite subir alguna imágen adjunta o archivo relacionado a alguna noticia o contenido. Muchas veces estos ficheros no son validados correctamente, aveces simplemente usan una triste validación por javascript o simplemente validan la extensión, sin tomar en cuenta el mime. Entonces es cuando debemos subir algún fichero en php o el lenguaje que sea necesario para ejecutar arbitrariamente el código que necesitemos.
• FTP password discovery: Esto es súper sencillo. Con este punto me refiero al intentar descargar ficheros de configuración (mediante Directori Transversal) y tener acceso a distintos usuarios y claves para probar el acceso ftp y poder subir algún fichero que nos permita lograr nuestro propósito.
• PhpMy/PgAdmin: Simplemente, con este último punto, quiero hacer referencia a buscar instalaciones de phpmyadmin o phppgadmin en otros sitios del servidor. Generalmente, un servidor aloja más de un sitio web y más de alguno es vulnerable (nuestra puerta de entrada).

Hay veces que hay que recorrer todo el servidor para encontrar una única puerta de entrada. Como bien dije en el último punto, generalmente los servidores alojan más de un sitio web y nunca falta que uno de ellos sea vulnerable, el que nos permita el ingreso directo o indirecto al servidor y de esta forma ejecutar código arbitrariamente.