Etiquetacsrf

Nueva Vulnerabilidad Cross-Site Scripting (XSS) en Banco Santander

santander-chile-650x400

Desde hace un tiempo que Banco Santander ha expuesto a sus clientes y usuarios a una serie de incidentes de seguridad, como por ejemplo solicitud de claves por parte de los ejecutivos hacia nuevos clientes, vulnerabilidades que permitieron el acceso a parte del código fuente, fallas de seguridad que facilitaban el phishing, etc. Varias de estas vulnerabilidades fueron expuestas en este blog, luego que no se tuviera respuesta por parte del banco, como se puede ver en esta lista de posts.

Actualmente, en el año 2015, Santander demuestra que no ha aprendido nada, desde el punto de vista de la gestión como en el ámbito técnico. Continuan ignorando las alertas de seguridad que se denuncian y por otro lado continuan entregando un servicio que no cumple con un mínimo de seguridad.

Las vulnerabilidades se repiten año tras año, por ejemplo en este caso mostraré un Cross-Site Scripting (XSS) que afecta a la Banca Personas, un problema de seguridad que es facil de detectar, facil de mitigar y facil de explotar.

Seguir leyendo

Vulnerabilidad en LinkedIn permite obtencion de contraseñas

El proceso para iniciar sesión de LinkedIn es vulnerable a ataques de fuerza bruta y es posible, mediante un diccionario, descubrir la password de usuarios. Este ataque es factible debido a un error en la validación del token de seguridad (Csrf token) que permite enviar tantos request remotos como queramos, probando distintos usuarios y usando el mismo token.
La única protección que existe, es que luego de decenas de intentos, nos muestra un Captcha, sin embargo, luego de esperar un tiempo y con un nuevo Token, es posible continuar con el ataque.

Para obtener un Token y poder probar el ataque, debemos atrapar el POST que se hace en el formulario de login y obtener el “sourceAlias” y “csrfToken”.

Cuando realizamos el ataque, no es necesario enviarle estos valores metiante POST, ya que no discrimina el métido por el cual se le entregan los valores, pudiendo generar un simple script que haga consultas mediante GET pasandole las variables por URL.

Seguir leyendo

Sitio web del Servicio Electoral (SERVEL) expone tus datos

Luego de que se propusieran la idea de inscribir automaticamente a todos los chilenos, el SERVEL tuvo la brillante idea de poner la base de datos de todos los inscritos disponible para cualquier persona en su sitio web.

Con solo ingresar el RUT o el nombre de una persona, es posible obtener su domicilio, por ejemplo:

El formulario no cuenta con un captcha para validar que sea una persona quien consulta los datos y tampoco tiene las validaciones necesarias para proteger request desde sitios remotos y asi poder evitar que un “bot” se dedique a hacer un dump de la base de datos.

Como el sistema de consultas es vulnerable a CSRF, con un pequeño script podemos obtener información de personas, por ejemplo:

15000XXX-7
LECAROS XXXXX ELENA XXXX
PILCO XX XXXXXX DPTO 106
————
15000002-5
XXXXXX NIETO XXXXXXXX ANDRES
SITIO XXXXXX EL SAUCE XXXXXXX
————
15000XXX-3
ROJAS XXXXXX PAMELA XXXXXXX
PJ LOS XXXXX XX
————
15000XXX-1
BELLO XXXXX SUSANA XXXXXX
DIEGO XXXXX XXXXX POBL. SAN JOSE
————
15000XXX-K
GONZALEZ XXX PATRICIA XXXX
ANIBAL PINTO XXXX PBL.M.ORIENTE
————

En esta prueba de concepto lo unico que hice fue un script que cuente de 15.000.000 a 15.000.010, obtenga el digito verificador de cada RUT y consulte con cURL o wget al sitio del SERVEL. Un bot podria ser programado para que recorra todos los rut y obtenga información sobre las personas.

Seguir leyendo

Vulnerabilidad permite el robo de información en el sistema del S.I.I

Ya han sido varias las vulnerabilidades que han afectado a este sistema, como pueden ver en Secureless, se han reportado vulnerabilidades correspondientes a redirección de URL abierta, es decir, el usuario podía ser redireccionado a cualquier URL externa sin su autorización y otras del tipo Cross-Site Scripting, que permite al atacante incrustar código html/javascript arbitrariamente y aprovecharse de la confianza que el usuario tiene sobre el sitio para robar información, suplantar su identidad mediante el robo de cookies o bien incrustando un formulario falso para que el usuario entregue sus datos de autentificación (rut, password) al atacante.

Esta es una demostración de que tener un sitio con SSL o HTTPS no significa que sea “seguro”.

DISCLAIMER: Antes que todo, me gustaría aclarar los motivos de hacer pública esta demostración. Hace varios meses intenté reportar la vulnerabilidad de Redirección de URL que afectaba al momento de iniciar sesión pero no obtuve respuesta y luego de haberla hecho publica, apareció solucionada. La última vulnerabilidad XSS que encontré logré reportarla al encargado de seguridad de la institución (gracias a un contacto que no tenía antes), la respuesta que obtuve fue:

Escalé al Area de Mantención , para que mitigue la vulnerabilidad, te enviaré e-mail cuando esté mitigada.

Muchas gracias por la información

1 mes despues de este correo, no he recibido ninguna notificación. Luego de haber dicho lo siguiente, hace 3 dias:

La vulnerabilidad apareció corregida.

Esta vez avisaré a los responsables pero no esperaré a que lo solucionen para hacer público este artículo. Creo que los usuarios del Servicio de Impuestos Internos debe conocer los riesgos de realizar trámites online con una plataforma que no brinda la suficiente seguridad.

Seguir leyendo

Fallos de seguridad en Huntcha.com

Huntcha.com es un sistema hecho para “encontrar a tu amor secreto”, ingresas tus datos, registras a tu amor secreto y si tu amor secreto te agrega a ti, entonces el sistema detecta esa coincidencia y te da la alerta. Por lo tanto, ingresando a la cuanta de algun usuario es posible saber quienes son “los amores secretos” de esa persona. Si esta persona está emparejada y está casado, se podría armar un lio mas o menos.

Según los Términos y Condiciones, respecto a la privacidad y protección de datos, podemos leer:

Política de Privacidad

En virtud de la Ley N°19.628 sobre Protección de la Vida Privada, la empresa respeta el deber de proteger los datos de carácter privado y personales de los usuarios, no dando acceso a ellos al público a menos que el propio usuario los de a conocer, por medio de la página web bajo su consentimiento, no pudiendo hacer responsable a la empresa por la información que el mismo entregue. La empresa se compromete a cuidar la seguridad de los datos personales tomando todas las medidas necesarias para esto, a fin de evitar la pérdida, mal uso o cualquier apropiación indebida de estos mismos.

Lo que más me llama la atención es que segun ellos, son 100% privados y seguros:

Dicen tener más de 20 mil usuarios, por lo que asegurar que los datos de esos 20 mil están 100% seguros y privados, es un poco irresponsable. Todos sabemos que la seguridad y la privacidad al 100% no existe.

He encontrado algunas vulnerabilidades en este sistema que puede permitir a un atacante obtener información de los usuarios que se encuentran autentificados. Explotando estas vulnerabilidades el atacante podría perfectamente suplantar la identidad de la persona o de su amor platónico.

Las vulnerabilidades son Cross-Site Request Forgery (CSRF) y Cross-Site Scripting (XSS), combinandolas se puede explotar una funcionalidad que tiene el portal para enviar correos a “tus amigos” para invitarlos al portal, pudiendo modificar el mensaje y el destinatario. Además, no es necesario estar autentificado para poder explotar este fallo.

Seguir leyendo

El Phishing y el Banco Santander Chile

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.

Seguir leyendo