Página 16 de 51

Cross-Site Scripting en El Mercurio On-Line (EMOL)


EMOL es un portal web de noticias que tiene una gran cantidad de visitas a nivel nacional, según dicen es una de las principales plataformas “noticiosas” del país.

El bug esta en no filtrar los parametros de entrada cuando se muestra el error 404 de una pagina inexistente, por ejemplo: https://www.emol.com/pagina_no_existe

Mostrara el mensaje

Si cambiamos “pagina_no_existe” por “prueba_de_concepto
(https://www.emol.com/prueba_de_concepto) mostrará

Asi mismo, si insertamos codigo HTML o JavaScript, este sera ejecutado.

Seguir leyendo

[Tip] bzip2 vs pbzip2: Comprimir con bzip2 en forma paralela

Ya todos conocemos “bzip2“, un algoritmo de compresión sin perdida, pero no todos conocen la existencia del proyecto “pbzip2“, una implementación “paralela” del anterior; un algoritmo de compresión, basado en bzip2, que aprovecha los recursos de una máquina con SMP (Symmetric Multi-Processing).

PBZIP2 is a parallel implementation of the bzip2 block-sorting file compressor that uses pthreads and achieves near-linear speedup on SMP machines. The output of this version is fully compatible with bzip2 v1.0.2 or newer

(Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz)

En la imagen pueden ver los 3 procesos de pbzip2 consumiendo los 2 CPUs al 100%, de esta forma el tiempo de compresión es practicamente la mitad.
A simple vista, si bzip2 se demora 30 segundos, pbzip2 demora 15. Por ejemplo, con un archivo de texto (el típico dump sql) de tamaño 137Mb:
$ time bzip2 poc.sql

real 0m33.010s
user 0m32.788s
sys 0m0.147s

Y con pbzip2:
$ time pbzip2 poc.sql

real 0m19.827s
user 0m36.868s
sys 0m0.960s

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

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