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”,
[Leer Más →]
Etiquetas: Hacking · Seguridad · Sitios Vulnerables
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 http://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 http://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=http://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: http://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 
[Leer Más →]
Etiquetas: Hacking · Seguridad · Sitios Vulnerables
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.
[Leer Más →]
Etiquetas: Hacking · Interes general · Privacidad · Seguridad · Sitios Vulnerables
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
Etiquetas: Hacking · Programación · Seguridad · Tips
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.
Etiquetas: Hacking · Seguridad
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.
Etiquetas: Hacking · Interes general · Seguridad · Sitios Vulnerables
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.
[Leer Más →]
Etiquetas: Hacking · Interes general · Privacidad · Seguridad · Sitios Vulnerables
Se está poniendo de moda el phishing y el robo de datos bancarios para realizar transferencias no deseadas, cada vez son mas los usuarios afectados y muchos de ellos no logran recuperar su dinero, simplemente el banco no responde. Por un lado tienen razón, ya que quien entregó su información personal y privada fueron ellos mismos, pocas veces este tipo de robos son debido a una falla/bug/vulnerabilidad que afecte directamente al banco.
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!
[Leer Más →]
Etiquetas: Interes general · Proyectos · Seguridad · Sitios Vulnerables
Cuando digo “destrucción” de información no me refiero a simpemente eliminarla o purgarla del disco duro, sino a sobrescribirla y hacer imposible su restauración. Existen varias utilidades y formas de hacerlo, pero yo les mostraré tres utilidades/herramientas que nos ayudarán: dd, shred y wipe. La primera, nos ayudará a zero-izar un sector de nuestro disco duro, memoria o lo que sea. Las otras dos son herramientas que nos permitiran sobreescribir y eliminar definitivamente un archivo para que sea irrecuperable. shred viene por defecto en casi todas las distribuciones unixlike, wipe se puede instalar en cualquiera.
Según los manpages,
wipe:
Wipe is a secure file wiping utility. There are some low level issues that must be taken into consideration. One of these is that there must be some sort of write barrier between passes. Wipe uses fdatasync(2) (or fsync(2)) as a write barrier, or if fsync(2) isn’t available, the file is opened with the O_DSYNC or O_SYNC flag. For wipe to be effective, each pass must be completely written. To ensure this, the drive must support some form of a write barrier, write cache flush, or write cache disabling. SCSI supports ordered command tags, has a force media access bit for commands, and write cache can be disable on mode page 8. IDE/ATA drives support write cache flushes and write cache disabling. Unfortunetly, not all drives actually disable write cache when asked to. Those drives are broken. Write caching should always be disabled, unless your system is battery backed and always powers down cleanly.
shred:
Overwrite the specified FILE(s) repeatedly, in order to make it harder for even very expensive hardware probing to recover the data.
dd:
Copy a file, converting and formatting according to the operands
Vamos a lo practico.
[Leer Más →]
Etiquetas: GNU/Linux · Seguridad · Tips
